java分層架構的意義

『壹』 java的三層架構是什麼樣的

『貳』 怎麼理解JAVA中的三層結構

三層結構跟語言關系不大吧，都差不多。
一般Java的話，表示層（前端）可以用jsP，Flex等做，中間層用的是J2EE的伺服器，運行在Tomcat或者JBoss上，數據層可以用Hibernate來做。
。NET的話，前端就是ASP，中間層用C#寫。

『叄』 java web 三層架構的意義及實際開發中的對應

數據層：用於連接資料庫及基本操作，如最簡單的增刪改查等等
業務邏輯層：接受表現層的操作，調用數據層的方法在資料庫中實現
表現層：就是顯示給用戶看的，java web中一般是jsp

『肆』 java分層

com.公司名.系統名.模塊名
代碼目錄結構
Action : 負責頁面邏輯，將調用service的結果返回到頁面中
Service : 介面定義
---impl 介面的實現，負責業務邏輯
Domain 對應資料庫表的pojo
Dao : 只負責連接資料庫，從資料庫中查詢結果，包裝成對象後返回
util ：工具類

『伍』 為什麼JavaWeb項目要分層

首先讓我們坐著時光機回到n年前的web開發。
那個時候最早都是靜態的html頁面，後來有了資料庫，有了所謂的動態頁面，
然後程序猿在編碼的時候，會把所有的代碼都寫在頁面上，包括資料庫連接，包括事務控制，接收參數，各種校驗，各種邏輯，各種html/js/css代碼等等
怎麼樣？夠亂吧？像一坨那什麼一樣，這個頁面可能有成千上萬行？

那麼好，問題來了，回頭需要修改的時候，你怎麼辦？
你找個東西找半天，好不容易找到了，還不敢改，怕被其他地方用了，改出連帶問題。
頁面一出錯，定位不準到底是哪裡的問題，從頭到尾的挨個排查。
等等等等。

這就是大家常說的什麼叫可維護性，這也是為什麼越來越多的公司的規范要求不能寫復雜sql。

還記得之前在東軟的時候，一哥們寫了一個80多行的大sql來完成一個核心的查詢。
試問這個大sql天天在資料庫里run，還有性能可言？
再試問誰敢改？
後來項目要改需求還是出現bug了，那個sql要改動，寫sql的哥們改了好久才改好，因為時間長他也忘了，
再後來他離職了。。。

有人問，那簡單sql實現不了我的功能呀，怎麼辦？
從資料庫設計層面開始下手，要允許適當的冗餘，把表弄好，就迎刃而解了，這也是資料庫層面的一種解耦吧。

後來。。。
進入第二階段，大家痛定思痛，決定要把頁面和邏輯拆開，頁面只是負責顯示，邏輯都在後台。
這就出現了短暫的，在jsp里使用標簽調用bean的用法。bean里耦合了除了頁面之外的所有東西。

再後來。。。
進入了第三階段，大家又痛定思痛，決定要拆成三部分，就是大名鼎鼎的MVC。

再再後來。。。
衍生出來了類似於struts/springmvc等等的mvc框架
---------------
JavaWeb項目的層有2個維度。

第一個維度是MVC的三層：
M：model，模型層，包括了你的業務邏輯和資料庫操作，封裝好給視圖層使用的。
V：view，視圖層，僅僅做的是展示數據，不包含業務邏輯，主要是jsp/html等等
C：controller，控制層，負責接收請求，調用模型層處理業務邏輯並返回給視圖層。

第二個維度是java代碼里的三層：
controller：控制層，負責接收參數/解析參數/封裝參數，調用serivce，將service方法的返回值進行封裝（如果需要），返回數據/返回頁面，路由。
service：負責業務邏輯，事務控制在這層里做，被controller調用，以及調用。
：持久層，負責資料庫交互，被service調用。

這2個維度別弄混了喲。我今天主要說的是第二個維度的層喲。
我認為，第二個維度是第一個維度的延伸，其實第二個維度再加上一個表現層就完美了，這就為什麼有人說是4層架構。
---------------
前戲結束，步入正題：

有些學生朋友可能會問為什麼要分層呢？我本來可以在一個地方寫完的東西，非要散落在各個層中，都在一起不是挺好的嗎？
開發效率高呀~
跳來跳去的我腦子都暈啦。。。

這就是為什麼有人會把所有的東西都扔在一個層里，比如controller層。。。

其實我們可以在jsp上把所有的邏輯以及資料庫操作,數據展示全部寫在一起，耦合在一起，這樣開發起來貌似更快，
但是維護性非常差，有朝一日想改一個小地方，牽一發而動全一身，隱患很高，無法快速定位問題。
因此我們需要分層。
分層了之後，你理論上改了持久層的東西，邏輯層是不用變動的。

每個Dao類是跟每個表走，Dao的每個方法里就一個個的簡單sql，不包含任何業務邏輯，可以被不同的service復用和調用。

經過抽象後基本上都是通用的，因而我們在定義DAO層的時候可以將相關的方法定義完畢，
這樣的好處是在對Service進行擴展的時候不需要再對DAO層進行修改，提高了程序的可擴展性。

提高了程序的可擴展性。具體什麼時候做這些操作，怎麼做這些操作都由Service來處理。
（就像郭德綱的相聲里的一句話：「行了，你甭管了」）

而Service則不是，一個Service里可以會調用多個不同的，完成特定的業務邏輯，事務控制，
封裝Service層的業務邏輯有利於通用的業務邏輯的獨立性和重復利用性

同時，一個Service的方法也有可能被多個Controller的方法來調用。

邏輯出問題就在Service找問題，資料庫，sql有問題就在Dao層找問題，
參數解析錯誤，跳轉錯誤，就在Controller上找問題。
這樣快速定位問題，互不幹擾。

---------------
分層架構（這里會延伸到更廣闊的架構）：

回頭項目玩大了，怎麼辦？拆！！！

具體可以搜一下：maven分模塊開發，怎麼玩代碼依賴，怎麼玩微服務，怎麼玩SOA，怎麼玩RPC，怎麼玩bbo。

web項目發展有幾個階段啊

第一個階段（單一應用架構）：
所有代碼都耦合在一個項目里，放在一台伺服器上，這種all in one的方式是有好處的。
創業初期，不用什麼架構，走敏捷開發，最快速的實現需求才是王道。
你甭管我有多爛，我至少能跑起來，我至少能在外網上讓你訪問，讓你使用。
當然了，初期的訪問量很少，節省部署和運維成本才是王道呀。
聽阿里的講座，說淘寶的前期的版本用的就是一台PC機作為伺服器，所有的功能耦合在一個項目里，
每次往生產環境上發版本，要上傳一個600mb的包，呵呵。

第二個階段（垂直應用架構）：
哎喲，不錯哦。自己的兒子被越來越多的人訪問，訪問量激增，一台伺服器扛不住了，
沒事，我們可以玩負載均衡，玩集群。
但是！這種性能加速度其實會變得越來越小，因為你的項目是耦合在一起的。
這時，我們需要拆分項目，這里又有2個維度，按層拆，按模塊拆。
將拆好的不同項目分別部署在不同的伺服器上，並且再分不同的小集群。

第三個階段（分布式服務架構）：
唉呀媽呀，訪問量陡增，到這步你創業應該算成功了，開始燒投資人的錢了吧。
經過上面拆成了越來越多的模塊，模塊與模塊交互越來越多，怎麼辦？
這個時候我們需要把核心的業務抽出來，作為獨立的服務，慢慢發展成穩定的服務中心，
用來提升業務復用和整合。
就像阿里的大牛說過，沒有淘寶的積累，天貓能那麼快的出來嗎？
這個時候，你的緩存，資料庫，消息隊列等服務都應該是分布式的。

第四個階段（流動計算架構）
哎呀媽呀，訪問量又上了一個台階，翻了好幾百倍吖，腫么辦？
這個時候服務越來越多，一些容量和資源的浪費問題凸顯出來，
這時我們需要一個調度中心來基於訪問壓力動態的管理集群容量，
提高利用率。

第五個階段（雲計算架構）
抱歉，作者正在學習中，未完待續。

『陸』 java 分層架構中Logic層和Service層的區別為什麼會分成兩個

Logic層用來收取數據，處理數據
Service層用來調用方法，屬於業務邏輯層，負責調用多個Dao
在SSH框架中開始細分為Logic層與Service層

『柒』 請問JAVA三層架構、持久層、業務層、表現層都該怎麼理解和MVC三層模型有什麼區別

希望還有人來關注這個問題。
我們常常自提到java EE的三層或者四層結構。
四層架構：
展示層（web層）、業務邏輯層、數據訪問層、信息資源層
四層架構在是開發企業應用時使用的非常經典的劃分模式。
web層負責前端展示和用戶請求的處理。mvc是一個設計模式，主要用戶構建用戶界面，目的是把展示邏輯和邏輯分離。web層通常會使用MVC模式進行構建，經常使用的mvc框架包括spring mvc，struts等，都是在web層或者展示層使用的。
業務邏輯層一般應用中會有一層service抽象，實現核心業務邏輯，事務控制也在這一層實現。
數據訪問層也即層，重點負責資料庫訪問，完成持久化功能。
信息資源層主要服務資源的存儲。
所以mvc和四層（三層）結構有關系，四層架構是應用的體系（分層）結構，描述了整個應用的一個完整的劃分，而mvc是一個設計模式，通常會用於四層架構的展示層的構建上。希望我能講清楚。

『捌』 java中的4層架構，為什麼要將3層分層4層，這樣有什麼好處，4層後，每層是干什麼的

分層的好處就在於代碼清晰，結構分明，有利於修改和維護。增加代碼的可讀性。我6層的都用過。

『玖』 請問JAVA三層架構，持久層，業務層，表現層，都該怎麼理解和MVC三層模型有什麼區別

持久層用來固化數據，如常說的DAO層，操作資料庫將數據入庫
業務層用來實現整體的業務邏輯 如 前台獲得了數據，邏輯層去解析這些數據，效驗這些數據等操作
表現層很好解釋 你現在看到的網頁 一些界面 都屬於表現層的東西可以用一些Html，jsp，Swing來實現
至於mvc么對應的是 model（模型） view（視圖） Controller（控制）
在javaweb中就很好理解了再XX系統中，前台頁面屬於view 貫穿前台後台持久層的一套模型就是model（EJB，Spring來實現） 而連接前台後台進行邏輯操作的就是Controller（Struts來實現）

『拾』 闡述在java中是如何分層的，可以介紹MVC架構，以一個簡單的實例說明

MVC模式。
Model模式層
View視圖層
Controller控制器
視圖(View)代表用戶交互界面，對於Web應用來說，可以概括為HTML界面，但有可能為XHTML、XML和Applet。隨著應用的復雜性和規模性，界面的處理也變得具有挑戰性。一個應用可能有很多不同的視圖，MVC設計模式對於視圖的處理僅限於視圖上數據的採集和處理，以及用戶的請求，而不包括在視圖上的業務流程的處理。業務流程的處理交予模型(Model)處理。比如一個訂單的視圖只接受來自模型的數據並顯示給用戶，以及將用戶界面的輸入數據和請求傳遞給控制和模型。

模型(Model)：就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來說是黑箱操作，模型接受視圖請求的數據，並返回最終的處理結果。業務模型的設計可以說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應用例子，它從應用技術實現的角度對模型做了進一步的劃分，以便充分利用現有的組件，但它不能作為應用設計模型的框架。它僅僅告訴你按這種模型設計就可以利用某些技術組件，從而減少了技術上的困難。對一個開發者來說，就可以專注於業務模型的設計。MVC設計模式告訴我們，把應用的模型按一定的規則抽取出來，抽取的層次很重要，這也是判斷開發人員是否優秀的設計依據。抽象與具體不能隔得太遠，也不能太近。MVC並沒有提供模型的設計方法，而只告訴你應該組織管理這些模型，以便於模型的重構和提高重用性。我們可以用對象編程來做比喻，MVC定義了一個頂級類，告訴它的子類你只能做這些，但沒法限制你能做這些。這點對編程的開發人員非常重要。

業務模型還有一個很重要的模型那就是數據模型。數據模型主要指實體對象的數據 保存（持續化）。比如將一張訂單保存到資料庫，從資料庫獲取訂單。我們可以將這個模型單獨列出，所有有關資料庫的操作只限制在該模型中。

控制(Controller)可以理解為從用戶接收請求, 將模型與視圖匹配在一起，共同完成用戶的請求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個分發器，選擇什麼樣的模型，選擇什麼樣的視圖，可以完成什麼樣的用戶請求。控制層並不做任何的數據處理。例如，用戶點擊一個連接，控制層接受請求後, 並不處理業務信息，它只把用戶的信息傳遞給模型，告訴模型做什麼，選擇符合要求的視圖返回給用戶。因此，一個模型可能對應多個視圖，一個視圖可能對應多個模型。
MVC的一個形象的例子，我要去買一輛賓士車，那麼我先要去4S店，那麼這個店面就是控制層，他不會關心車子是什麼製造的，只管提供車給我。那麼車廠就是SERVICE層，他只管製造車子，把結果提供給4S店，那車子的零件又是怎麼來的呢？他就是通過更多的零件廠商來提供，那麼這些零件廠商就是DAO層。