Java的三大框架是什么？

java三大框架是：

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：網(wǎng)站設計、成都網(wǎng)站建設、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的東阿網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

1、Struts

為了解決這些問題，出現(xiàn)了Struts框架，它是一個完美的MVC實現(xiàn)，它有一個中央控制類（一個Servlet），針對不同的業(yè)務，我們需要一個Action類負責頁面跳轉(zhuǎn)和后臺邏輯運算，一個或幾個JSP頁面負責數(shù)據(jù)的輸入和輸出顯示，還有一個Form類負責傳遞Action和JSP中間的數(shù)據(jù)。JSP中可以使用Struts框架提供的一組標簽，就像使用HTML標簽一樣簡單，但是可以完成非常復雜的邏輯。從此JSP頁面中不需要出現(xiàn)一行包圍的Java代碼了。

可是所有的運算邏輯都放在Struts的Action里將使得Action類復用度低和邏輯混亂，所以通常人們會把整個Web應用程序分為三層，Struts負責顯示層，它調(diào)用業(yè)務層完成運算邏輯，業(yè)務層再調(diào)用持久層完成數(shù)據(jù)庫的讀寫。

使用JDBC連接來讀寫數(shù)據(jù)庫，我們最常見的就是打開數(shù)據(jù)庫連接、使用復雜的SQL語句進行讀寫、關閉連接，獲得的數(shù)據(jù)又需要轉(zhuǎn)換或封裝后往外傳，這是一個非常煩瑣的過程。

2、Hibernate

這時出現(xiàn)了Hibernate框架，它需要你創(chuàng)建一系列的持久化類，每個類的屬性都可以簡單的看做和一張數(shù)據(jù)庫表的屬性一一對應，當然也可以實現(xiàn)關系數(shù)據(jù)庫的各種表件關聯(lián)的對應。當我們需要相關操作是，不用再關注數(shù)據(jù)庫表。我們不用再去一行行的查詢數(shù)據(jù)庫，只需要持久化類就可以完成增刪改查的功能。使我們的軟件開發(fā)真正面向?qū)ο?，而不是面向混亂的代碼。我的感受是，使用Hibernate比JDBC方式減少了80％的編程量。

現(xiàn)在我們有三個層了，可是每層之間的調(diào)用是怎樣的呢？比如顯示層的Struts需要調(diào)用一個業(yè)務類，就需要new一個業(yè)務類出來，然后使用；業(yè)務層需要調(diào)用持久層的類，也需要new一個持久層類出來用。通過這種new的方式互相調(diào)用就是軟件開發(fā)中最糟糕設計的體現(xiàn)。簡單的說，就是調(diào)用者依賴被調(diào)用者，它們之間形成了強耦合，如果我想在其他地方復用某個類，則這個類依賴的其他類也需要包含。程序就變得很混亂，每個類互相依賴互相調(diào)用，復用度極低。如果一個類做了修改，則依賴它的很多類都會受到牽連。 為此，出現(xiàn)Spring框架。

3、Spring

Spring的作用就是完全解耦類之間的依賴關系，一個類如果要依賴什么，那就是一個接口。至于如何實現(xiàn)這個接口，這都不重要了。只要拿到一個實現(xiàn)了這個接口的類，就可以輕松的通過xml配置文件把實現(xiàn)類注射到調(diào)用接口的那個類里。所有類之間的這種依賴關系就完全通過配置文件的方式替代了。所以Spring框架最核心的就是所謂的依賴注射和控制反轉(zhuǎn)。

現(xiàn)在的結(jié)構(gòu)是，Struts負責顯示層，Hibernate負責持久層，Spring負責中間的業(yè)務層，這個結(jié)構(gòu)是目前國內(nèi)最流行的Java Web應用程序架構(gòu)了。另外，由于Spring使用的依賴注射以及AOP（面向方面編程），所以它的這種內(nèi)部模式非常優(yōu)秀，以至于Spring自己也實現(xiàn)了一個使用依賴注射的MVC框架，叫做Spring MVC，同時為了很好的處理事物，Spring集成了Hibernate，使事物管理從Hibernate的持久層提升到了業(yè)務層，使用更加方便和強大。

Struts框架是2000年就開始起步了，技術(shù)相當成熟，目前全球Java開發(fā)中Struts框架是顯示層技術(shù)中當之無愧的王者。它擁有大量的用戶群和很好的開發(fā)團隊。這也是國內(nèi)大部分Java軟件公司對新進員工的基本要求。

Java的三種技術(shù)架構(gòu)是什么?

Java從1998年誕生到現(xiàn)在已經(jīng)20多年了。使用它開發(fā)的軟件不計其數(shù)。

在整個發(fā)展過程中，出現(xiàn)的架構(gòu)方式有：

單體架構(gòu)：將所有的功能代碼寫在一個工程中

垂直架構(gòu)：將功能代碼按業(yè)務進行拆分成一個個的單體架構(gòu)模式

分布式微服務架構(gòu)：將功能按照業(yè)務分為一個個微小的服務，每個服務都是獨立的進程，單獨部署，容易擴展，能夠很好的應對高并發(fā)等

網(wǎng)格架構(gòu)：未來的可能的架構(gòu)模式。

java架構(gòu)有哪些

Java架構(gòu)：

軟件架構(gòu)作為一個概念，體現(xiàn)在技術(shù)和業(yè)務兩個方面。

從技術(shù)角度來說：軟件架構(gòu)隨著技術(shù)的革新不斷地更新其內(nèi)容，軟件架構(gòu)建立于當前技術(shù)和一些基本原則的基礎之上。

先說一些基本原則：

分層原則：分層是為了降低軟件深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟件有了層次結(jié)構(gòu)。

模塊化原則：模塊化是化解軟件廣度復雜的必然手段，模塊化的目的就是讓軟件分工。

接口實現(xiàn)分離原則隨著軟件模塊化的不斷深入改進，面向接口編程而不是面向?qū)崿F(xiàn)編程可以讓復雜度日趨增高的軟件降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發(fā)，軟件也從微觀進行了細致的規(guī)范化。

還有兩個比較小但很重要的原則：

細節(jié)隱藏原則很顯然把復雜問題簡化，把難看的細節(jié)隱去，能讓軟件結(jié)構(gòu)更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade（外觀）模式就很能體現(xiàn)這個原則的精神。

依賴倒置原則隨著軟件結(jié)構(gòu)的進一步發(fā)展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態(tài)可插拔要求不端增大。依賴倒置原則可看視為接口實現(xiàn)分離原則的深化，根據(jù)此原則的精神，軟件進入了工具時代。這個原則有點類似于知名的好萊塢法則：Don't call us, we'll call you。

以上這些原則奠定了我們的軟件架構(gòu)的價值指標。但軟件架構(gòu)畢竟是建立在當前技術(shù)之上的。而每一代技術(shù)都有架構(gòu)模式。過去的不再說了，讓我們現(xiàn)在就來看一下當前流行的技術(shù)，以及當前我們能采用的架構(gòu)。

因為面向?qū)ο笫钱斍白盍餍虚_發(fā)技術(shù)，且設計模式的大量使用使面向?qū)ο蟮淖呦虺墒欤鴶?shù)據(jù)庫是當前最有效的存儲結(jié)構(gòu)、web界面是當前最流行的用戶接口，所以當前最典型的三層次架構(gòu)就架構(gòu)在以上幾項技術(shù)的基礎之上，用數(shù)據(jù)庫作存儲層、用面向?qū)ο髞韺崿F(xiàn)業(yè)務層、用web來作為用戶接口層。我們從三層次架構(gòu)談起：

因為面向?qū)ο蠹夹g(shù)和數(shù)據(jù)庫技術(shù)不適配，所以在標準三層次架構(gòu)的基礎上，我們增加了數(shù)據(jù)持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現(xiàn)技術(shù)。cmp和entity bean技術(shù)因為其實現(xiàn)復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的后期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選

在業(yè)務層,因為當前業(yè)務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術(shù)來保證我們的適應變化的能力，在標準j2ee系統(tǒng)中session bean負責業(yè)務處理，且有不錯的性能表現(xiàn)，但采用ejb系統(tǒng)對業(yè)務架構(gòu)模式改變太大，且其復雜而昂貴，業(yè)務代碼移植性差。而spring 作為一個bean配置的輕量級架構(gòu)，漂亮的IOC模式實現(xiàn)，對業(yè)務架構(gòu)影響小，所以推薦作為中間層業(yè)務框架。

在用戶結(jié)構(gòu)層,雖然servlet/jsp/jstl/javaBean 能夠?qū)崿F(xiàn)MVC架構(gòu),但終究過于粗糙。struts對MVC架構(gòu)的實現(xiàn)就比較完美，Taperstry也極好地實現(xiàn)MVC架構(gòu)，且采用基于事件的方式，非常誘人，惜其不夠成熟，我們?nèi)耘f推薦struts作為用戶接口層基礎架構(gòu)。

因為業(yè)務層是三層次架構(gòu)中最有決定意義的，所以讓我們回到業(yè)務層細致地分析一下，在復雜的業(yè)務我們常常需要以下基礎服務的一種或幾種：事務一致性服務acid(tool:jta/jts)、并發(fā)加鎖服務concurrentlock、池化管理服務cache、訪問控制服務(tool:jaas)、流程控制服務workflow、動態(tài)實現(xiàn)服務IOC，串行化消息服務(tool:jms)、負載平衡服務blance等。如果我們不采用重量級應用服務器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現(xiàn)其中一些服務。雖然我們大多情況下，不需要所有這些服務，但實現(xiàn)起來卻非易事。幸運的是我們有大量的開源實現(xiàn)代碼,但采用開源代碼卻常常是件不輕松的事。

隨著xml作為結(jié)構(gòu)化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發(fā)重要,而隨著xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema來設計xml文檔格式,然后采用java binding來生成java bean 會成為主要編程模式,而這又進一步使數(shù)據(jù)中心向xml轉(zhuǎn)移,使在中小數(shù)據(jù)量上,愈發(fā)傾向于以xquery為查詢語言的xml數(shù)據(jù)庫。最近還有一個趨勢,microsoft,ibm等紛紛大量開發(fā)中間軟件如(microsoft office之infopath)，可以直接從xml schema 生成 錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟件的架構(gòu)有非常重大的影響。至于面向服務架構(gòu)(SOA)前景如何，三層次架構(gòu)什么時候走入歷史，現(xiàn)在還很難定論。

aop的發(fā)展也會對軟件架構(gòu)有很深的影響，但在面向?qū)ο蠹軜?gòu)里，無論aspectJ還是jboss-aop抑是aspectWerks、nanning都有其自身的嚴重問題:維護性很差,所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。

rdf,owl作為w3c語義模型的標志性的語言,也很難想象能在當前業(yè)務架構(gòu)發(fā)揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結(jié)構(gòu)。那么對軟件架構(gòu)也會有深遠影響。

有關架構(gòu)設計的一些忠告：

盡量建立完整的持久對象層.可獲得高回報

盡量將各功能分層,分塊,每一模塊均依賴假定的其它模塊的外觀

不能依賴靜態(tài)數(shù)據(jù)來實現(xiàn)IOC模式，應該依賴數(shù)據(jù)特征接口，靜態(tài)數(shù)據(jù)僅是數(shù)據(jù)特征接口實現(xiàn)方式之一

架構(gòu)設計時xml是支持而不是依賴.但可以提供單一的xml版本的實現(xiàn)

從業(yè)務角度說：軟件架構(gòu)應是深刻體現(xiàn)業(yè)務內(nèi)部規(guī)則的業(yè)務架構(gòu)，但因為業(yè)務變化頻纴，所以軟件架構(gòu)很難保持恒定不變，但業(yè)務的頻繁變化不應是軟件架構(gòu)大規(guī)模頻繁變化的原因，軟件架構(gòu)應是基于變化的架構(gòu)。

一種業(yè)務有其在一段時間內(nèi)穩(wěn)定存在的理由(暫且不談)，業(yè)務內(nèi)部有許多用例，每一種用例都有固定的規(guī)則，每一規(guī)則都有一些可供判定的項，每一項從某一維度來觀察都是可測量的，我們的架構(gòu)首先必須保證完美適應每一項每一種測量方式，很多失敗的架構(gòu)都是因為很多項的測量方式都發(fā)生變更這種微觀變化中。

每個用例都有規(guī)則，我們在作業(yè)務用例分析，常常假定一些規(guī)則是先驗的，持久穩(wěn)定的，然而后來的業(yè)務改變常常又證明這種看法是錯誤的，然而常常我們的架構(gòu)已經(jīng)為之付出了不可挽回的代價。大量事實證明：規(guī)則的變化常常用例變化的根本原因。所以我們的架構(gòu)要盡可能適應規(guī)則的變化，盡可能建立規(guī)則模版。

每個用例都關系著不同的角色。每一個用例的產(chǎn)生都必然是因為角色的變更（注意：不是替換，而是增強或減弱），所以注意角色的各種可能情況，對架構(gòu)的設計有舉足輕重的意義。在我們當前的三層架構(gòu)里，角色完美地對應接口概念。

在一個系統(tǒng)里很多用例都相互關聯(lián),考慮到每個用例均有可能有不同的特例，所以在架構(gòu)設計中，盡量采用依賴倒置原則。如架構(gòu)許可可采用消息通信模式(JMS)。這樣可降低耦合度。

現(xiàn)在我們談一下業(yè)務穩(wěn)定存在理由對業(yè)務的影響。存在即是合理，在這里當然是正確的。業(yè)務因人而存在，所以問業(yè)務存在的理由即是問不同角色的需要這項業(yè)務的理由以及喜歡不喜歡當前業(yè)務用例的理由，所有這樣的角色都應該在系統(tǒng)里預留。《待續(xù)》

在架構(gòu)設計中有幾個原則可以考慮：

用例盡量細分

用例盡量抽象

角色盡量獨立

項測量獨立原則

追求簡單性

這里未提供相關的例子，例子會在以后的更新時提供。

業(yè)務和模式之間的關系

業(yè)務中的一些用例之間的關系常常和一些常規(guī)的模式很相似。但隨著時間的演化，慢慢地和先前的模式有了分歧。這是個正常的現(xiàn)象。但這對系統(tǒng)架構(gòu)卻要求非常高，要求系統(tǒng)架構(gòu)能適應一些模式的更替。在這里我們盡可能早地注意到用例之間的相互角色變化，為架構(gòu)更新做好準備.

本文標題：java代碼架構(gòu) java開發(fā)平臺的編程構(gòu)架分類
標題網(wǎng)址：http://jinyejixie.com/article34/dodphpe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、云服務器、Google、營銷型網(wǎng)站建設、網(wǎng)站內(nèi)鏈、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)