1、什麼是架構模式？
剛作了軟考題，有一道關於提問設計模式是什麼的，設計模式是一套解決相似問題的經驗的總結。採用設計模式的目的是爲了可重用代碼。而架構模式也一個通用的、可重用的解決方案。我以爲他們的區別是，設計模式跟代碼更有直接關係，html
架構模式站在系統全局的角度解決子系統之間的關係、功能需求與非功能的優先級與取捨原則等。java
2、分層模式
（參考https://www.cnblogs.com/IcanFixIt/p/7518146.html）mysql
這種模式也稱爲多層體系架構模式。它能夠用來構造能夠分解爲子任務組的程序，每一個子任務都處於一個特定的抽象級別。每一個層都爲下一個提供更高層次服務。分層模式的關鍵點在於肯定依賴：即經過分層，能夠限制子系統間的依賴關係，web
使系統以更鬆散的方式耦合，從而更易於維護。區分層次的目的是爲了「高內聚低耦合」的思想。在軟件體系架構設計中，分層式結構是最多見，也是最重要的一種結構。常見的分層模式結構有如下幾種：spring
一）通常信息系統中最多見的是以下所列的4層：表示層，業務邏輯層，持久層，應用層。
模式介紹：
- 表示層(也稱爲UI層)：主要對用戶的請求接受，以及數據的返回，爲客戶端提供應用程序的訪問。
- 應用層(也稱爲服務層)：服務層的做用就是將表現層與業務邏輯層之間完成解耦。那麼表現層中就不會出現任何的業務代碼，固然這樣帶來的好處也是顯而易見的，就是當咱們修改業務層代碼時，咱們不須要修改表現層的代碼，
固然若是服務層設計的很差，那麼可能會形成反效果。sql
- 業務邏輯層(也稱爲領域層)：主要是針對具體的問題的操做，也能夠理解成對數據層的操做，對數據業務邏輯處理，若是說數據層是積木，那邏輯層就是對這些積木的搭建。無疑是系統架構中體現核心價值的部分。它的關注點
主要集中在業務規則的制定、業務流程的實現等與業務需求有關的系統設計，也便是說它是與系統所應對的領域邏輯有關數據庫
- 數據訪問層(也稱爲持久化層)：主要是針對非原始數據（數據庫或者文本文件等存放數據的形式）的操做層，而不是指原始數據，也就是說，是對數據庫的操做，而不是數據，具體爲業務邏輯層或表示層提供數據服務。
案例分析---SSH的分層：
一、在表示層中，首先經過JSP頁面展現信息設計模式
二、在服務交互層中實現交互，負責傳送請求(Request)和接收響應(Response)，而後Struts根據配置文件(struts-config.xml)將ActionServlet接收到的Request委派給相應的Action處理，而後action進行對請求處理並轉發給JSP頁面。數組
三、在業務邏輯層中，管理服務組件的Spring IoC容器負責向Struts2提供具體的Action對象，提供業務模型(Model)組件和該組件的協做對象數據處理(DAO)組件完成業務邏輯，並提供事務處理、緩衝池等容器組件以提高系統性能和保證數據的完整性。架構
四、在數據訪問層中，則依賴於Hibernate的對象化映射和數據庫交互，處理DAO組件請求的數據，並返回處理結果，給業務邏輯層。
以***重大技術需求爲例
若是需求徵集頁面接到了一個添加需求的請求，用戶填完表單並提交，在web.xml配置了Struts2的攔截器，攔截表單提交請求，服務交互層根據Struts2的配置文件去服務交互層層的DemandAction,尋找保存的方法，該方法調用業務邏輯層
的方法demandService.Save(),業務邏輯層的這個方法又繼續調用數據持久層的方法把數據保存到數據庫，調用完畢以後返回save，服務交互層根據返回的結果save由服務交互層調用業務層的顯示需求列表方法，業務層調用數據持久層數
數據庫讀取需求信息，回到表現層顯示需求列表界面。Spring提供的IoC容器，咱們能夠將對象之間的依賴關係交由Spring進行控制管理服務組件的Spring IoC容器負責向Struts2提供具體的Action對象，提供業務模型(Model)組件和該組件的
協做對象數據處理(DAO)組件完成業務邏輯。
二）微軟推薦的分層式結構通常分爲三層，從下至上分別爲：數據訪問層、業務邏輯層（又或稱爲領域層）、表示層。
- 表現層（UI）：通俗講就是展示給用戶的界面，用於顯示數據和接收用戶輸入的數據，爲用戶提供一種交互式操做的界面。
- 業務邏輯層（BLL）：針對具體問題的操做，也能夠說是對數據層的操做，對數據業務邏輯處理。對於數據訪問層而言，它是調用者；對於表示層而言，它倒是被調用者。也將業務邏輯層稱爲領域層。
- 數據訪問層（DAL）：該層所作事務直接操做數據庫，針對數據的增、刪、改、查。若是要加入ORM的元素，那麼就會包括對象和數據表之間的mapping，以及對象實體的持久化。也稱爲是持久層。數據訪問層中包含實體層（Model 實體層）
JavaWeb中典型的三層架構是：Jsp+Struts/spring+Hibernate的開發模式
簡單工廠模式與三層架構：
三層在簡單工廠的思想和基礎上，爲了達到更好的可複用性，可擴展性，可維護性和靈活性，把簡單工廠的邏輯層進一步的分解，把邏輯層分解爲邏輯判斷層和數據訪問層，讓她們彼此直接的耦合度達到最低。不論是簡單工廠仍是三層架構，它們
之間的最終目的是解耦，最終的效果是達到「高內聚，低耦合」的效果。三層架構咱們並不陌生，它是來源於簡單工廠，可是高於簡單工廠，它把簡單工廠的粒度更加細化了，可是它們最終的目的是達到解耦。
一個餐館的例子，若是從買菜上菜到作菜都是一我的，那我的生病了這個餐館就不能營業了。若是有三我的分別負責招待客人、買菜、作菜，他們三我的有一我的生病的話，另外兩個作簡單的調整是能夠營業的。也就是一層發生修改不會影響另外兩層的
工做。招待客人的至關於表示層，只負責招待客人，作菜的至關於業務邏輯層按照表示層給的參數作菜，買菜的至關於數據訪問層，只負責按照廚師給的單子買菜。
三）展現層，業務層，持久層，和數據庫層。
如表1-1，有時候，業務層和持久層會合併成單獨的一個業務層，尤爲是持久層的邏輯綁定在業務層的組件當中。所以，有一些小的應用可能只有3層，一些有着更復雜的業務的大應用可能有5層或者更多的分層。與第一個四層不一樣的是，展現層負責處
理全部的界面展現以及交互邏輯，業務層負責處理請求對應的業務，持久層負責對數據的操做，數據層負責操做數據庫。
案例分析：
（參考https://blog.csdn.net/bboyfeiyu/article/details/45136299#t1）
爲了演示分層架構是如何工做的，想象一個場景，如表1-4，用戶發出了一個請求要得到客戶的信息。黑色的箭頭是從數據庫中得到用戶數據的請求流，紅色箭頭顯示用戶數據的返回流的方向。在這個例子中，用戶信息由客戶數據和訂單數組組成(客戶下的訂單)。
用戶界面只管接受請求以及顯示客戶信息。它無論怎麼獲得數據的，或者說獲得這些數據要用到哪些數據表。若是用戶界面接到了一個查詢客戶信息的請求，它就會轉發這個請求給用戶委託(Customer Delegate)模塊。這個模塊能找到業務層裏對應的模塊處理
對應數據(約束關係)。業務層裏的customer object聚合了業務請求須要的全部信息(在這個例子裏獲取客戶信息)。這個模塊調用持久層中的 customer dao 來獲得客戶信息，調用order dao來獲得訂單信息。這些模塊會執行SQL語句，而後返回相應的數據給業務層。當 customer object收到數據之後，它就會聚合這些數據而後傳遞給 customer delegate,而後傳遞這些數據到customer screen 展現在用戶面前。
三 分層模式的特色
使用場景：
- 通常的桌面應用程序
- 電子商務Web應用程
模式特色：
- 每一個模塊必須屬於某個層次，爲上層提供服務；同時委派任務給下層模塊。
- 任何一個模塊，都不能逆層次調用；屬於下層的模塊，不得調用（耦合）上層或上層次的模塊。任何一個模塊，都不得跨層次調用。
設計模式實現：
門面模式 ——咱們對於每一個模塊或者每一個層次都會設計一個「門面」來下降耦合的複雜程度。
策略模式——抽象層次會隱藏底層的實現細節，這就是策略模式最基本的設計，咱們每每會把上層做爲功能接口，下層做爲可選的策略來實現。
優勢
一、開發人員能夠只關注整個結構中的其中某一層；
二、能夠很容易的用新的實現來替換原有層次的實現；
三、能夠下降層與層之間的依賴；
四、有利於標準化；
五、利於各層邏輯的複用。
六、結構更加的明確
七、在後期維護的時候，極大地下降了維護成本和維護時間
缺點
一、下降了系統的性能。這是不言而喻的。若是不採用分層式結構，不少業務能夠直接造訪數據庫，以此獲取相應的數據，現在卻必須經過中間層來完成。
二、有時會致使級聯的修改。這種修改尤爲體如今自上而下的方向。若是在表示層中須要增長一個功能，爲保證其設計符合分層式結構，可能須要在相應的業務邏輯層和數據訪問層中都增長相應的代碼。
三、增長了開發成本。