一、前言
大家好，接近一年的時間沒有怎麼書寫博客了，一方面是工作上比較忙，同時生活上也步入正軌，事情比較繁多，目前總算是趨於穩定，可以有時間來完善以前沒有寫完的系列，也算是對自己這段時間工作和生活上總結，同時也加深下自己對架構和
設計方面的理解，由於本人的寫作水平有限，所以在書寫的深度和書寫的格式上還有很多的缺點，還希望大家多多指出。
二、開篇
本篇我們將針對系統架構中的分層進行講述，分析不同分層模式的優缺點及應用的場景，當然我們會結合一些案例來介紹這些分層，通過案例來證明各種分層的好處與優缺點，本篇作爲開篇主要是介紹這個分層系列中會講述到的幾種分層模式實踐，
由於很多分層模式也是自己在工作過程中總結和經驗積累下來的，可能存在個人理解或用法上錯誤之處，還請大家指出，我予以及時更正。
三、內容提要
1、前言
2、開篇
3、本文提綱
4、分層模式
4.1、分層架構介紹
4.1、後端分層多層
4.1.1、普通三層架構
4.1.2、多層架構
4.2、前端分層模式
4.2.1、MVC模式
4.2.2、MVP模式
4.2.3、MVVM模式
5、結束語
6、系列進度
7、下篇預告
四、分層模式
4.1、分層架構介紹
架構首先是分爲不同層次的和不同視圖的，例如架構有五種視圖：邏輯視圖、物理視圖、數據視圖、運行視圖、開發視圖。我們今天不講解這幾個不同的視圖，而是講解分層對於軟件設計的意義及關注點，之前我也發過一片單機軟件架構的文章，文
章中提到了一個軟件從簡單到複雜的全過程，而軟件架構也是一個迭代的過程，是一個循序漸進，不斷完善的過程。
我們今天交流的主要是邏輯緯度的分層，關於物理視圖的分層，本篇先不講解，因爲那塊更復雜，同時也更重要，對於大型的互聯網軟件或大型的互聯網網站，更關注的是物理架構方面的設計。下面我們就來針對當前的一些分層模式來進行講解，並
且進行簡要的分析和應用場景介紹。
4.2、後端分層架構
一、普通三層架構
三層架構(3-tier architecture) 通常意義上的三層架構就是將整個業務應用劃分爲：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即爲了“高內聚，低耦合”的思想。
三層架構圖
對於傳統的三層架構圖，可能因爲大家在實際的場景中，因爲大家對這些分層運用的不同，會出現適應的場景的不同，而且有很多的大型軟件或項目，都是採用三層架構，我們可以通過引入一些開源的組件或自定義組件來構建非常靈活或擴展性很強
的分層結構，雖然是3層架構，但是卻可以滿足大部分的場景。
A、場景：
最原始的三層結構可能如下：
ThreeArchitecture.Entities：實體定義層，該層主要是完成各分層間數據傳遞並且最終通過該實體實現DAL層與數據庫交互的數據傳輸。
ThreeArchitecture.DAL：數據訪問層，通過調用實體層，通過Ado.net編程，實現數據持久化，例如可以支持多種數據庫，sqlserver、oracle、mysql、sqlite.
ThreeArchitecture.BLL：業務邏輯層，通過調用實體層、數據訪問層，實現整個業務系統的核心功能，完成系統業務的處理。
ThreeArchitecture.UI：用戶界面交互層，用戶通過該用戶界面與業務系統進行交互，完成業務邏輯操作與交互。
根據上面的解決方案的分層及組織，下面針對以下幾個場景來分析，分析三層架構中遇到的問題，應該如何解決這些問題。
1）、如果需要實現多數據庫支持。我想業務系統能夠從sqlserver向oracle數據遷移，或反之。
這樣在現有的項目結構方式，就無法滿足，但是我們可以增加新的接口層來實現這個要求。
例如可以通過如下項目方式來組織：
修改原有的項目劃分結構，加入DAL.Interface層次。定義數據訪問接口，通過不同的數據訪問實現，然後通過數據訪問層工廠，來構建不同的數據庫訪問實例。
這塊具體的代碼我就不貼出了，應該比較簡單。
同時原來的ThreeArchitecture.BLL 調用的不是直接調用數據庫訪問層實現，而是調用數據訪問層接口。不依賴於具體的實現，而是依賴接口，這樣可以實現解耦，提供了很強的擴展性。
2）、如果我要求業務邏輯層實現也不一定固定，例如在醫療行業的話，每個醫院的業務系統或業務流程都不相同，那麼假設我們希望溝通統一的UI界面，而不是隨着業務邏輯的改變而修改UI，那麼我們就需要進行如下的設計：
項目的結構方式類似上面的DAL層的變化。
在原來的基礎上改進：
ThreeArchitecture.BLL.Interface：定義業務邏輯接口，主要目標是隔離UI與業務邏輯實現間的依賴關係，將實現代碼調用修改爲接口調用方式。
ThreeArchitecture.BLL.A：A場景下的實現，A的業務邏輯。
ThreeArchitecture.BLL.B：B場景下的實現，B的業務邏輯。
3）、縱向和橫向擴展性需求場景，例如場景變化靈活性較高時，工廠模式無法很好應對，需要維護大量的工廠代碼。
可以採用開源的相關組件，來實現解耦及隔離，例如 數據訪問層可以採用Nhibernate或Entityframework來實現，關於Nhibernate的文章，園子裏面已經有很多的文章介紹了，我就不介紹了，
引入Nhibernate以後，項目的結構，回到如下模式
ThreeArchitecture.DAL.Nhibernate：NHibernate實現數據訪問層接口，Nhibernate支持目錄主流的大部分數據庫，所以不需要按照1）中的方案去做，只需要實現一次即可。
ThreeArchitecture.DAL.EntityFramework：EntityFramework實現數據訪問層接口，EntityFramework支持Oracle,SQLServer，其他的數據庫支持的不太好。
在上面的場景中，例如在A場景下，我希望使用A業務層、B場景下使用B實現，而且，不希望系統中維護大量的工廠代碼，那麼我們就請出來當前架構或框架設計的核心組件IOC
IOC：控制反轉（Inversion of Control，英文縮寫爲IoC）是一個重要的面向對象編程的法則來削減計算機程序的耦合問題，也是當前主流框架的核心。 控制反轉還有一個名字叫做依賴注入（Dependency Injection）。簡稱DI。
採用了IOC以後，接口和實現就可以通過配置的方式來動態的設置，而且調用的方式也變得更簡單，不需要其他複雜的代碼設定，目前市面上的IOC容器很多，我瞭解的主要是以下幾種：
Unity：微軟的輕量級IOC容器。提供了比較強的註冊和動態查找機制，同時提供了強大的AOP，幾乎無所不在。
Autofac：Autofac是一款IOC框架，比較於其他的IOC框架，如Spring.NET，Unity，Castle等等所包含的，它很輕量級性能上也是很高的
Spring.NET：參考java的sprint 框架的.net平臺下的實現，比較強大。
Castle：Castle是針對.NET平臺下的一個非常優秀的開源項目，從數據訪問框架 ORM到依賴注入容器，再到WEB層的MVC框架、AOP，基本包括了整個開發過程中的所有東西，爲我們快速的構建企業級的應用程序提供了很好的服務
Ninject：是一個快如閃電、超輕量級的基於.Net平臺的依賴注入框架。它能夠幫助你把應用程序分離成一個個鬆耦合、高內聚的模塊，然後用一種靈活的方式組裝起來。通過使用Ninject配套你的軟件架構，那麼代碼將會變得更加容易編寫、重用性強、
易於測試和修改。
關於上面介紹的部分IOC容器的用法整體上來說都差不多，具體的大家可以網上搜索下，案例和demo比較多。
二、多層架構
上面介紹了普通的三層架構，多層架構顧名思義就是在三層架構之上，通過擴展及應用場景的挖掘，衍生出來的適應不同場景的架構模式，下面我主要是來介紹以下幾種多層架構模式
A、服務層模式
在上面介紹的3層架構模式中，存在一個缺陷，如果我們構建的軟件或系統支持分佈式或者需要對外提供服務的時候，這個場景就無法滿足了，所以這個時候服務層就出現了，就是在BLL層的基礎上進行包裝，包裝成可以對外提供調用的分佈式服務。
經過改造後的項目結構如下：
在項目中加入了03.解決方案文件夾，同時添加項目 ThreeArchitecture.Service項目。
ThreeArchitecture.Service:主要是提供幾個作用：1、將業務邏輯層進行封裝，對外提供業務服務調用。2、通過外觀模式，屏蔽業務邏輯內部方法。3、降低業務邏輯層與UI層的依賴，業務邏輯接口或實現的變化不會影像UI層。4、降低UI層調用的請求次
數及數據往返。
在上面的結構中，我們說了Service層次的作用，目前還少加入了一層，DTO(數據傳輸對象層)，該層負責屏蔽後端的實體層，將UI層需要的數據進行重新的定義和封裝，在實際的業務場景下，後端實現或存儲的數據遠比用戶需要的數據要龐大和負責，所
以前端需要的數據相對來說要麼是組合的，要麼是抽取的，不是完整的，因爲我們在設計數據存儲格式上都會有一些額外的設計和考慮。
加入了ThreeArchitecture.DTO層後，前端的UI層，只是知道DTO的存在，同時前端需要的數據都在一個Dto中，這樣，每次調用服務層的時候，只需要調用一次就可以完成所有的業務邏輯操作，而不是原來的直接調用業務邏輯層那樣的，需要調用多
次，對於分佈式場景下，減少服務調用的次數，尤其重要。
B、DDD架構模式：
Presentation Layer: 負責與客戶端進行交互
Application Layer: 負責協調領域層之間的交互
Domain Layer: 軟件的核心，所有相關的Domain information都在這，可以看成是Business Logic Layer，但不完全是
Infrastructure Layer: 負責各層之間的交互溝通、資料存取、安全性管理及通用Library
更常見的是如下層次
我們建議的方式如下：
Repository層使用ORM映射或SQL命令等方式把持久化數據轉化爲領域對象，然後根據業務邏輯設計對應領域層服務Domain Service 。接着應用層進行操作上的協調，利用Repository、領域模型、領域層服務Domain Service 完成業務需要，再通過數
據轉換器把領域對象Domain Object轉化爲數據傳輸對象DTO。最後，利用遠程通訊技術把應用層的服務（Application Service）對外開放。
注意留意的是SOA系統中，UI表現層與Application Service應用層服務是實現分離的，表現層可以同時調用多方的遠程服務來完成工作。
在上面的架構中還可以加入領域事件、查詢接口、分佈式服務層，來靈活運用和組合，來解決項目中適應場景的不同。
4.3、前端分層架構
A、MVC架構模式
MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯和數據顯示分離的方法組織代碼，將業務邏輯被聚集到一個部件裏面，在界面和用戶圍繞數據的交互能被改進和個性化
定製的同時而不需要重新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。
目前在主流的框架中都支持該模式，例如構建winform程序中可以通過MVC模式來分離界面層中的控件與後端服務間的交互。降低耦合及依賴。
web上通過asp.net MVC框架來實現前端頁面及後端控制器之間的隔離。
視圖
視圖是用戶看到並與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演着重要的角色，但一些新的技術已層出不窮，它們包括Adobe Flash和像XHTML，XML/XSL,WML
等一些標識語言和Web services.
MVC好處是它能爲應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理髮生，不管這些數據是聯機存儲的還是一個僱員列表，作爲視圖來講，它只是作爲一種輸出數據並允許用戶操縱的方式。
模型
模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。一個模型能爲多個視圖提供數據，由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重複性。
控制器
控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求，所以當單擊Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後再確定用哪個視圖來顯示返回的數
據。
ASP.NET MVC
關於具體的代碼，大家可以嘗試新建一個MVC的應用程序，微軟提供的默認的MVC的代碼模版中就有相關的示例代碼，具體的我就不介紹了。
Winform的MVC模式
winform的MVC模式，主要是通過事件的方式來實現。
B、MVP架構模式
MVP 是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。作爲一種新的模式，MVP與MVC有着一個重大的區別：在MVP中View並不直接使用Model，它們之間
的通信是通過Presenter (MVC中的Controller)來進行的，所有的交互都發生在Presenter內部，而在MVC中View會從直接Model中讀取數據而不是通過 Controller。
在MVC裏，View是可以直接訪問Model的！從而，View裏會包含Model信息，不可避免的還要包括一些業務邏輯。 在MVC模型裏，更關注的Model的不變，而同時有多個對Model的不同顯示，及View。所以，在MVC模型裏，Model不依賴於Vie
w，但是View是依賴於Model的。不僅如此，因爲有一些業務邏輯在View裏實現了，導致要更改View也是比較困難的，至少那些業務邏輯是無法重用的。
1、View和Model完全解耦，兩者不發生直接關聯，通過Presenter進行通信。
2、Presenter並不是與具體的View耦合，而是和一個抽象的View Interface耦合，View Interface相當於一個契約，抽象出了對應View應實現的方法。只要實現了這個接口，任何View都可以與指定Presenter兼容，從而實現了P Logic的複用性和視圖的無縫替換。
3、View在MVP裏應該是一個“極瘦”的概念，最多也只能包含維護自身狀態的邏輯，而其它邏輯都應實現在Presenter中。
總的來說，使用MVP模式可以得到以下兩個收益：
1、將UI和P Logic兩個關注點分離，得到更乾淨和單一的代碼結構。
2、實現了P Logic的複用以及View的無縫替換。
展示器層作爲核心的控制，實現view和model之間的完全解耦。關於該架構設計的具體demo 後面來介紹
C、MVVM架構模式
MVVM是Model-View-ViewModel的簡寫。
微軟的WPF帶來了新的技術體驗，如Sliverlight、音頻、視頻、3D、動畫……，這導致了軟件UI層更加細節化、可定製化。同時，在技術層面，WPF也帶來了 諸如Binding、Dependency Property、Routed Events、Command、DataTemplate、C
ontrolTemplate等新特性。MVVM（Model-View-ViewModel）框架的由來便是MVP（Model-View-Presenter）模式與WPF結合的應用方式時發展演變過來的一種新型架構框架。它立足於原有MVP框架並且把WPF的新特性揉合進去，以應對客戶日
益複雜的需求變化。
MVVM模式和MVC模式一樣，主要目的是分離視圖（View）和模型（Model），有幾大優點
1. 低耦合。視圖（View）可以獨立於Model變化和修改，一個ViewModel可以綁定到不同的"View"上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。
2. 可重用性。你可以把一些視圖邏輯放在一個ViewModel裏面，讓很多view重用這段視圖邏輯。
3. 獨立開發。開發人員可以專注於業務邏輯和數據的開發（ViewModel），設計人員可以專注於頁面設計，使用Expression Blend可以很容易設計界面並生成xaml代碼。
4. 可測試。界面素來是比較難於測試的，而現在測試可以針對ViewModel來寫。
1. 視圖(View)
視圖負責界面和顯示。它通過DataContext(數據上下文)和ViewModel進行數據綁定，不直接與Model交互。 可以綁定Behavior/Comand來調用ViewModel的方法，Command是View到ViewModel的單向通行，通過實現Silverlight提供的IComand接口來實現綁定，讓View觸發事件，ViewModel來處理事件，以解決事件綁定功能。
2. 視圖模型(ViewModel)
視圖模型主要包括界面邏輯和模型數據封裝，Behavior/Command事件響應處理，綁定屬性定義和集合等。它是View和Model的橋樑，是對Model的抽象，比如：Model中數據格式是“年月日”，可以在ViewModel中轉換Model的數據爲“日月年”供View顯示。
實現視圖模型需要實現Silverlight提供的接口INotifyPropertyChanged， INotifyPropertyChanged接口用於實現屬性和集合的變更通知(Change Notifications)。使得在用戶在視圖上所做的操作都可以實時通知到視圖模型，從而讓視圖模型對象有的模型進行正確的業務操作。
View的代碼隱藏(Code-Behind)部分可能包含界面邏輯或者應用邏輯的代碼，這些代碼會很難進行單元測試，應根據具體情況儘量避免。
3. 模型(Model)
Model與MVC模式一樣，Model用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。它具有對數據直接訪問的權利，例如對數據庫的訪問，Model不依賴於View和ViewModel，也就是說，模型不關心會被如何顯示或是如何被操作，
模型也不能包含任何用戶使用的與界面相關的邏輯。Model在實際開發中根據實際情況可以進行細分。比如在廣州市城鄉規劃資源平臺就將Model將Service和Reposiroty結合爲WCF服務由ViewModel進行調用。
一般來說實際的項目中會採用以下的模式來做，而不是直接採用傳統的MVVM模式，而是結合MVP或MVC模式來做。
上圖中的P層是整個項目的核心，負責處理View層顯示的數據來源及用戶操作的響應的處理，通過綁定viewModel中的command的處理來與後端服務進行交互，展示器層會調用後端的WCF服務來讀取數據，也就是讀取DataModel 然後修改View
Model。通過WPF提供的通知機制，來修改view的呈現。
MVC、MVP、MVVM對比
| 標題 | MVC | MVP | MVVM |
| 特點 | 高內聚、低耦合-一個控制器可以控制多個視圖 | 高內聚、低耦合-解決MVC中View依賴Model的問題 | 高內聚、低耦合-解決winform中存在的問題。解決view和Model之間的依賴，屏蔽view改變帶來的影響。 |
| 應用場景 | 前端與後端交互架構設計（CS或BS） | 前端與後端交互架構設計（CS或BS） | 前端與後端交互架構設計-WPF或Web通過js實現 |
五、結束語
通過上面軟件架構模式的介紹，大家對這些軟件架構的模式有了一定的瞭解，後面的關於分層中篇、後篇就是結合一些具體的案例來進行代碼的編寫的講解和實現。當然如果大家有比較感興趣的議題，也請提出來，可以根據這些議題，然後將上面介
紹的這些模式來去實現。
也歡迎大家針對我提出的這些思路進行討論，提出不同的看法和想法，另如果需要更深層次的討論，可以QQ與我聯繫。
關於上面介紹的只寫架構模式，我已經全部實現，如果需要相關的技術支持，請找我，或者您有什麼建議或意見，都請聯繫我。