一、前言大家好，接近一年的時(shí)間沒(méi)有怎么書(shū)寫(xiě)博客了，一方面是工作上比較忙，同時(shí)生活上也步入正軌，事情比較繁多，目前總算是趨于穩(wěn)定，可以有時(shí)間來(lái)完善以前沒(méi)有寫(xiě)完的系列，也算是對(duì)自己這段時(shí)間工作和生活上總結(jié)，同時(shí)也加深下自己對(duì)架構(gòu)和設(shè)計(jì)方面的理解，由于本人的寫(xiě)作水平有限，所以在書(shū)寫(xiě)的深度和書(shū)寫(xiě)的格式上還有很多的缺點(diǎn)，還希望大家多多指出。二、 開(kāi)篇本篇我們將針對(duì)系統(tǒng)架構(gòu)中的分層進(jìn)行講述，分析不同分層模式的優(yōu)缺點(diǎn)及應(yīng)用的場(chǎng)景，當(dāng)然我們會(huì)結(jié)合一些案例來(lái)介紹這些分層，通過(guò)案例來(lái)證明各種分層的好處與優(yōu)缺點(diǎn)，本篇作為開(kāi)篇主要是介紹這個(gè)分層系列中會(huì)講述到的幾種分層模式實(shí)踐，由于很多分層模式也是自己在工作過(guò)程中總結(jié)和經(jīng)驗(yàn)積累下來(lái)的，可能存在個(gè)人理解或用法上錯(cuò)誤之處，還請(qǐng)大家指出，我予以及時(shí)更正。三、 內(nèi)容提要1、 前言2、 開(kāi)篇3、 本文提綱4、 分層模式4.1、 分層架構(gòu)介紹4.1、 后端分層多層4.1.1、普通三層架構(gòu)4.1.2多層架構(gòu)4.2、 前端分層模式MVC模式MVP模式MVVM模式5、 結(jié)束語(yǔ)6、 系列進(jìn)度7、 下篇預(yù)告四、分層模式4.1、 分層架構(gòu)介紹架構(gòu)首先是分為不同層次的和不同視圖的，例如架構(gòu)有五種視圖：邏輯視圖、物理視圖、數(shù)據(jù)視圖、運(yùn)行視圖、開(kāi)發(fā)視圖。我們今天不講解這幾個(gè)不同的視圖，而是講解分層對(duì)于軟件設(shè)計(jì)的意義及關(guān)注點(diǎn)，之前我也發(fā)過(guò)一片單機(jī)軟件架構(gòu)的文章，文章中提到了一個(gè)軟件從簡(jiǎn)單到復(fù)雜的全過(guò)程，而軟件架構(gòu)也是一個(gè)迭代的過(guò)程，是一個(gè)循序漸進(jìn)，不斷完善的過(guò)程。我們今天交流的主要是邏輯緯度的分層，關(guān)于物理視圖的分層，本篇先不講解，因?yàn)槟菈K更復(fù)雜，同時(shí)也更重要，對(duì)于大型的互聯(lián)網(wǎng)軟件或大型的互聯(lián)網(wǎng)網(wǎng)站，更關(guān)注的是物理架構(gòu)方面的設(shè)計(jì)。下面我們就來(lái)針對(duì)當(dāng)前的一些分層模式來(lái)進(jìn)行講解，并且進(jìn)行簡(jiǎn)要的分析和應(yīng)用場(chǎng)景介紹。4.2、 后端分層架構(gòu)一、普通三層架構(gòu)三層架構(gòu)（3-tierarchitectuB常意義上的三層架構(gòu)就是將整個(gè)業(yè)務(wù)應(yīng)用劃分為：表現(xiàn)層（UI）、業(yè)務(wù)邏輯層（BLL）、數(shù)據(jù)訪問(wèn)層（DAL）。區(qū)分層次的目的即為了“高內(nèi)聚，低耦合”的思想。實(shí)現(xiàn)與用戶交互邏數(shù)狂凈久化-實(shí)現(xiàn)對(duì)舷庫(kù)或文件庫(kù)的攝作用戶交換界面層用戶交換界面層業(yè)務(wù)邏糧層-實(shí)規(guī)與用戶交旦的邏輯實(shí)現(xiàn).是峑個(gè)系統(tǒng)的咳心用戶交互界玄層；用戶攝惟或交互的?界奩呈丸.界直的好壞及易用程虞決走了用戶的満曹度及質(zhì)量薦三層架構(gòu)圖對(duì)于傳統(tǒng)的三層架構(gòu)圖，可能因?yàn)榇蠹以趯?shí)際的場(chǎng)景中，因?yàn)榇蠹覍?duì)這些分層運(yùn)用的不同，會(huì)出現(xiàn)適應(yīng)的場(chǎng)景的不同，而且有很多的大型軟件或項(xiàng)目，都是采用三層架構(gòu)，我們可以通過(guò)引入一些開(kāi)源的組件或自定義組件來(lái)構(gòu)建非常靈活或擴(kuò)展性很強(qiáng)的分層結(jié)構(gòu)，雖然是3層架構(gòu)，但是卻可以滿足大部分的場(chǎng)景。A、場(chǎng)景：最原始的三層結(jié)構(gòu)可能如下：知翼艮方ThreeArchitertured(4個(gè)項(xiàng)目〕卜回ThreeArchitectijr&.6[JL>圄Thr^-eArchitcctuFC..DALB匣]ThreeArchftectyr^.EntTtiesb匱］ThreeArchitectufe.LIIThreeArchitecture.Entitie實(shí)體定義層，該層主要是完成各分層間數(shù)據(jù)傳遞并且最終通過(guò)該實(shí)體實(shí)現(xiàn)DAL層與數(shù)據(jù)庫(kù)交互的數(shù)據(jù)傳輸。ThreeArchitecture.DAL數(shù)據(jù)訪問(wèn)層，通過(guò)調(diào)用實(shí)體層，通過(guò)A編程，實(shí)現(xiàn)數(shù)據(jù)持久化，例如可以支持多種數(shù)據(jù)庫(kù)，sqlserveroraclemysql、sqlite.ThreeArchitecture.BLL業(yè)務(wù)邏輯層，通過(guò)調(diào)用實(shí)體層、數(shù)據(jù)訪問(wèn)層，實(shí)現(xiàn)整個(gè)業(yè)務(wù)系統(tǒng)的核心功能，完成系統(tǒng)業(yè)務(wù)的處理。ThreeArchitecture.UI用戶界面交互層，用戶通過(guò)該用戶界面與業(yè)務(wù)系統(tǒng)進(jìn)行交互，完成業(yè)務(wù)邏輯操作與交互。根據(jù)上面的解決方案的分層及組織，下面針對(duì)以下幾個(gè)場(chǎng)景來(lái)分析，分析三層架構(gòu)中遇到的問(wèn)題，應(yīng)該如何解決這些問(wèn)題。、如果需要實(shí)現(xiàn)多數(shù)據(jù)庫(kù)支持。我想業(yè)務(wù)系統(tǒng)能夠從sqlserver向oracle數(shù)據(jù)遷移，或反之。這樣在現(xiàn)有的項(xiàng)目結(jié)構(gòu)方式，就無(wú)法滿足，但是我們可以增加新的接口層來(lái)實(shí)現(xiàn)這個(gè)要求。例如可以通過(guò)如下項(xiàng)目方式來(lái)組織：SIK^^ThreeArrhiterture'丄EOLDALt>叵]ThreeArehitecture.DAL.Interfae電P-匣ThreeArehitecture.DALOra<le-卜園ThreeArchiiecture.DALSQlServerPE3ThreeArchitecture.BLLb更IThreeArthitecture^EntitiesP回ThreeArchitecture.U[修改原有的項(xiàng)目劃分結(jié)構(gòu)，加入DAL.Interface層次。定義數(shù)據(jù)訪問(wèn)接口，通過(guò)不同的數(shù)據(jù)訪問(wèn)實(shí)現(xiàn)，然后通過(guò)數(shù)據(jù)訪問(wèn)層工廠，來(lái)構(gòu)建不同的數(shù)據(jù)庫(kù)訪問(wèn)實(shí)例。這塊具體的代碼我就不貼出了，應(yīng)該比較簡(jiǎn)單。同時(shí)原來(lái)的ThreeArchitecture.BLL調(diào)用的不是直接調(diào)用數(shù)據(jù)庫(kù)訪問(wèn)層實(shí)現(xiàn)，而是調(diào)用數(shù)據(jù)訪問(wèn)層接口。不依賴(lài)于具體的實(shí)現(xiàn)，而是依賴(lài)接口，這樣可以實(shí)現(xiàn)解耦，提供了很強(qiáng)的擴(kuò)展性。2）、如果我要求業(yè)務(wù)邏輯層實(shí)現(xiàn)也不一定固定，例如在醫(yī)療行業(yè)的話，每個(gè)醫(yī)院的業(yè)務(wù)系統(tǒng)或業(yè)務(wù)流程都不相同，那么假設(shè)我們希望溝通統(tǒng)一的UI界面，而不是隨著業(yè)務(wù)邏輯的改變而修改UI,那么我們就需要進(jìn)行如下的設(shè)計(jì)：項(xiàng)目的結(jié)構(gòu)方式類(lèi)似上面的DAL層的變化。ESI屛夬方K'ThreeArchitecture'（8個(gè)項(xiàng)目）丿&01.DALt>更Thr??Architecture.DALlnterfaceP西ThrecArchitecture,DAL.Oracleb回ThreeArchitecture.DAL,SQLServerJ&02.BLLb回ThreeArchitecture.BLLAP叵IThreeArchitecture^BlLBThreeArchitecture*BLLJnterfaceb 畫(huà)ThreeArchitecturePEntitie5-t> 回ThreeArchitecture.Ul在原來(lái)的基礎(chǔ)上改進(jìn)：ThreeArchitecture.BLL.Interfac定義業(yè)務(wù)邏輯接口，主要目標(biāo)是隔離UI與業(yè)務(wù)邏輯實(shí)現(xiàn)間的依賴(lài)關(guān)系，將實(shí)現(xiàn)代碼調(diào)用修改為接口調(diào)用方式。ThreeArchitecture.BLL.AA場(chǎng)景下的實(shí)現(xiàn)，A的業(yè)務(wù)邏輯。ThreeArchitecture.BLL.BB場(chǎng)景下的實(shí)現(xiàn)，B的業(yè)務(wù)邏輯。3）、縱向和橫向擴(kuò)展性需求場(chǎng)景，例如場(chǎng)景變化靈活性較高時(shí)，工廠模式無(wú)法很好應(yīng)對(duì)，需要維護(hù)大量的工廠代碼?？梢圆捎瞄_(kāi)源的相關(guān)組件，來(lái)實(shí)現(xiàn)解耦及隔離，例如數(shù)據(jù)訪問(wèn)層可以采用Nhibernate或Entityframework來(lái)實(shí)現(xiàn)，關(guān)于Nhibernate的文章，園子里面已經(jīng)有很多的文章介紹了，我就不介紹了，引入Nhibernate以后，項(xiàng)目的結(jié)構(gòu)，回到如下模式Q翼關(guān)方^ThreeArchftecture'（8個(gè)項(xiàng)目）丿￡|01.DALb叵］ThreeArchitecture.DAL.EntityFramework口叵］Thr^Arehitc-rture.DAL.1nt?rft>回ThreeArchitecture.CiALIMHibe^rnate■&02.BLLA回ThreeArchitecttre.BLLA卜匿|ThreeArchitecture,BLL,B>?TBirecArchitecture.&LLJnterf^cePE3Thi^eA世hit亡ctu峠￡刑弗卅t>回ThreeArehiterture.U!ThreeArchitecture.DAL.NhibernateNHibernate實(shí)現(xiàn)數(shù)據(jù)訪問(wèn)層接口，Nhibernate支持目錄主流的大部分?jǐn)?shù)據(jù)庫(kù)，所以不需要按照1）中的方案去做，只需要實(shí)現(xiàn)一次即可。ThreeArchitecture.DAL.EntityFramewor：EntityFramework實(shí)現(xiàn)數(shù)據(jù)訪問(wèn)層接口，EntityFramework支持Oracle,SQLServer，其他的數(shù)據(jù)庫(kù)支持的不太好。在上面的場(chǎng)景中，例如在A場(chǎng)景下，我希望使用A業(yè)務(wù)層、B場(chǎng)景下使用B實(shí)現(xiàn)，而且，不希望系統(tǒng)中維護(hù)大量的工廠代碼，那么我們就請(qǐng)出來(lái)當(dāng)前架構(gòu)或框架設(shè)計(jì)的核心組件IOCIOC:控制反轉(zhuǎn)（InversionofContro英文縮寫(xiě)為IoC）是一個(gè)重要的面向?qū)ο缶幊痰姆▌t來(lái)削減計(jì)算機(jī)程序的耦合問(wèn)題，也是當(dāng)前主流框架的核心?？刂品崔D(zhuǎn)還有一個(gè)名字叫做依賴(lài)注入（DependencyInjectio?。簡(jiǎn)稱(chēng)DI。采用了IOC以后，接口和實(shí)現(xiàn)就可以通過(guò)配置的方式來(lái)動(dòng)態(tài)的設(shè)置，而且調(diào)用的方式也變得更簡(jiǎn)單，不需要其他復(fù)雜的代碼設(shè)定，目前市面上的IOC容器很多，我了解的主要是以下幾種：Unity微軟的輕量級(jí)IOC容器。提供了比較強(qiáng)的注冊(cè)和動(dòng)態(tài)查找機(jī)制，同時(shí)提供了強(qiáng)大的AOP，幾乎無(wú)所不在。Autofac：Autofac是一款I(lǐng)OC框架，比較于其他的IOC框架，如Spring.NET，Unity,Castie等等所包含的，它很輕量級(jí)性能上也是很高的Spring.NET：參考java的sprint框架的.net平臺(tái)下的實(shí)現(xiàn)，比較強(qiáng)大。Castie：Castie是針對(duì).NET平臺(tái)下的一個(gè)非常優(yōu)秀的開(kāi)源項(xiàng)目，從數(shù)據(jù)訪問(wèn)框架0RM到依賴(lài)注入容器，再到WEB層的MVC框架、AOP，基本包括了整個(gè)開(kāi)發(fā)過(guò)程中的所有東西，為我們快速的構(gòu)建企業(yè)級(jí)的應(yīng)用程序提供了很好的服務(wù)Ninject是一個(gè)快如閃電、超輕量級(jí)的基于.Net平臺(tái)的依賴(lài)注入框架。它能夠幫助你把應(yīng)用程序分離成一個(gè)個(gè)松耦合、高內(nèi)聚的模塊，然后用一種靈活的方式組裝起來(lái)。通過(guò)使用Ninject配套你的軟件架構(gòu)，那么代碼將會(huì)變得更加容易編寫(xiě)、重用性強(qiáng)、易于測(cè)試和修改。關(guān)于上面介紹的部分IOC容器的用法整體上來(lái)說(shuō)都差不多，具體的大家可以網(wǎng)上搜索下，案例和demo比較多。二、多層架構(gòu)上面介紹了普通的三層架構(gòu)，多層架構(gòu)顧名思義就是在三層架構(gòu)之上，通過(guò)擴(kuò)展及應(yīng)用場(chǎng)景的挖掘，衍生出來(lái)的適應(yīng)不同場(chǎng)景的架構(gòu)模式，下面我主要是來(lái)介紹以下幾種多層架構(gòu)模式A、服務(wù)層模式在上面介紹的3層架構(gòu)模式中，存在一個(gè)缺陷，如果我們構(gòu)建的軟件或系統(tǒng)支持分布式或者需要對(duì)外提供服務(wù)的時(shí)候，這個(gè)場(chǎng)景就無(wú)法滿足了，所以這個(gè)時(shí)候服務(wù)層就出現(xiàn)了，就是在BLL層的基礎(chǔ)上進(jìn)行包裝，包裝成可以對(duì)外提供調(diào)用的分布式服務(wù)。經(jīng)過(guò)改造后的項(xiàng)目結(jié)構(gòu)如下:G靄吳方g'ThreeArchitectur^（9個(gè)項(xiàng)目）J￡1OO.Entiti^s4更ThreeArchitecture.EntitiesJSI01.DAL卜S3threeArchitectsre.DAL.SntltyFrarri^vork>SThrecArchitecture*DALJntl>叵］Thr^eArrhiit^rtijft.DALNHibe^nat^J已02.BLL卜SThreeArcSiiterture.BLLAbH3ThreeArchitectijrfr.BLL.Bl>吏］ThreeArchitectjrenBLLInterfaceJ同03.Service卜<a|ThreeArchitecture.Service丿￡）05.UIt>畫(huà)ThreeArchiterture.UI在項(xiàng)目中加入了03.解決方案文件夾，同時(shí)添加項(xiàng)目ThreeArchitecture.Servi（項(xiàng)目。ThreeArchitecture.Servic主:要是提供幾個(gè)作用：1、將業(yè)務(wù)邏輯層進(jìn)行封裝，對(duì)外提供業(yè)務(wù)服務(wù)調(diào)用。2、通過(guò)外觀模式，屏蔽業(yè)務(wù)邏輯內(nèi)部方法。3、降低業(yè)務(wù)邏輯層與UI層的依賴(lài)，業(yè)務(wù)邏輯接口或?qū)崿F(xiàn)的變化不會(huì)影像UI層。4、降低UI層調(diào)用的請(qǐng)求次數(shù)及數(shù)據(jù)往返。在上面的結(jié)構(gòu)中，我們說(shuō)了Service層次的作用，目前還少加入了一層，DT0（數(shù)據(jù)傳輸對(duì)象層），該層負(fù)責(zé)屏蔽后端的實(shí)體層，將UI層需要的數(shù)據(jù)進(jìn)行重新的定義和封裝，在實(shí)際的業(yè)務(wù)場(chǎng)景下，后端實(shí)現(xiàn)或存儲(chǔ)的數(shù)據(jù)遠(yuǎn)比用戶需要的數(shù)據(jù)要龐大和負(fù)責(zé)，所以前端需要的數(shù)據(jù)相對(duì)來(lái)說(shuō)要么是組合的，要么是抽取的，不是完整的，因?yàn)槲覀冊(cè)谠O(shè)計(jì)數(shù)據(jù)存儲(chǔ)格式上都會(huì)有一些額外的設(shè)計(jì)和考慮。碩解塊方^ThreeArchitecture'（10個(gè)項(xiàng)目）丄000.EntitiesP畫(huà)ThreeArchkecture-EntrtiesJ01.DALb回ThreeArchitecture.DALEntityFramew-orkP廚ThreeArchitecture.DAUnttrfN"D畫(huà)ThreeArchkecture,DAL+NHibernateJE02.BLLb回ThreeArchitecture-BLLAPE3ThreeArchitecture.BLL.BP固ThreeArchitecture.BLLInterfaceJQ03.ServiceD國(guó)ThreeArchitecture-DTOi>亟ThreeArchitecture,Service止E05.UID回ThrHArehitKtufe>UI加入了ThreeArchitecture.DTO層后，前端的UI層，只是知道DTO的存在，同時(shí)前端需要的數(shù)據(jù)都在一個(gè)Dto中，這樣，每次調(diào)用服務(wù)層的時(shí)候，只需要調(diào)用一次就可以完成所有的業(yè)務(wù)邏輯操作，而不是原來(lái)的直接調(diào)用業(yè)務(wù)邏輯層那樣的，需要調(diào)用多次，對(duì)于分布式場(chǎng)景下，減少服務(wù)調(diào)用的次數(shù)，尤其重要。B、DDD架構(gòu)模式：PresentationLayer負(fù)責(zé)與客戶端進(jìn)行交互ApplicationLayer負(fù)責(zé)協(xié)調(diào)領(lǐng)域?qū)又g的交互DomainLayer:軟件的核心，所有相關(guān)的Domaininformation都在這，可以看成是BusinessLogicLayer但不完全是InfrastructureLaye負(fù)責(zé)各層之間的交互溝通、資料存取、安全性管理及通用Library更常見(jiàn)的是如下層次用戶界面 Web服務(wù)表現(xiàn)層基礎(chǔ)結(jié)構(gòu)層表現(xiàn)層基礎(chǔ)結(jié)構(gòu)層基礎(chǔ)結(jié)構(gòu)層我們建議的方式如下:Repository層使用0RM映射或SQL命令等方式把持久化數(shù)據(jù)轉(zhuǎn)化為領(lǐng)域?qū)ο?，然后根?jù)業(yè)務(wù)邏輯設(shè)計(jì)對(duì)應(yīng)領(lǐng)域?qū)臃?wù)DomainService。接著應(yīng)用層進(jìn)行操作上的協(xié)調(diào)，利用Repository、領(lǐng)域模型、領(lǐng)域?qū)臃?wù)DomainService完成業(yè)務(wù)需要，再通過(guò)數(shù)據(jù)轉(zhuǎn)換器把領(lǐng)域?qū)ο驞omainObject轉(zhuǎn)化為數(shù)據(jù)傳輸對(duì)象DTO。最后，利用遠(yuǎn)程通訊技術(shù)把應(yīng)用層的服務(wù)(ApplicationServiCe對(duì)外開(kāi)放。注意留意的是SOA系統(tǒng)中，UI表現(xiàn)層與ApplicationService用層服務(wù)是實(shí)現(xiàn)分離的，表現(xiàn)層可以同時(shí)調(diào)用多方的遠(yuǎn)程服務(wù)來(lái)完成工作。在上面的架構(gòu)中還可以加入領(lǐng)域事件、查詢接口、分布式服務(wù)層，來(lái)靈活運(yùn)用和組合，來(lái)解決項(xiàng)目中適應(yīng)場(chǎng)景的不同。4.3、前端分層架構(gòu)A、MVC架構(gòu)模式MVC全名是ModelViewController是模型(model)—視圖(view)—控制器(controlle的縮寫(xiě)，一種軟件設(shè)計(jì)典范，用一種業(yè)務(wù)邏輯和數(shù)據(jù)顯示分離的方法組織代碼，將業(yè)務(wù)邏輯被聚集到一個(gè)部件里面，在界面和用戶圍繞數(shù)據(jù)的交互能被改進(jìn)和個(gè)性化定制的同時(shí)而不需要重新編寫(xiě)業(yè)務(wù)邏輯。MVC被獨(dú)特的發(fā)展起來(lái)用于映射傳統(tǒng)的輸入、處理和輸出功能在一個(gè)邏輯的圖形化用戶界面的結(jié)構(gòu)中。Contro11erDispatcherDispatcherRoutesWebServerBrowser目前在主流的框架中都支持該模式，例如構(gòu)建winform程序中可以通過(guò)MVC模式來(lái)分離界面層中的控件與后端服務(wù)間的交互。降低耦合及依賴(lài)。web上通過(guò)MVC框架來(lái)實(shí)現(xiàn)前端頁(yè)面及后端控制器之間的隔離。視圖視圖是用戶看到并與之交互的界面。對(duì)老式的Web應(yīng)用程序來(lái)說(shuō)，視圖就是由HTML元素組成的界面，在新式的Web應(yīng)用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術(shù)已層出不窮，它們包括AdobeFlash和像XHTML，XML/XSL,WML等一些標(biāo)識(shí)語(yǔ)言和Webservices.MVC好處是它能為應(yīng)用程序處理很多不同的視圖。在視圖中其實(shí)沒(méi)有真正的處理發(fā)生，不管這些數(shù)據(jù)是聯(lián)機(jī)存儲(chǔ)的還是一個(gè)雇員列表，作為視圖來(lái)講，它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。模型模型表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。在MVC的三個(gè)部件中，模型擁有最多的處理任務(wù)。一個(gè)模型能為多個(gè)視圖提供數(shù)據(jù)，由于應(yīng)用于模型的代碼只需寫(xiě)一次就可以被多個(gè)視圖重用，所以減少了代碼的重復(fù)性?？刂破骺刂破鹘邮苡脩舻妮斎氩⒄{(diào)用模型和視圖去完成用戶的需求，所以當(dāng)單擊Wed頁(yè)面中的超鏈接和發(fā)送HTML表單時(shí)，控制器本身不輸出任何東西和做任何處理。它只是接收請(qǐng)求并決定調(diào)用哪個(gè)模型構(gòu)件去處理請(qǐng)求，然后再確定用哪個(gè)視圖來(lái)顯示返回的數(shù)據(jù)。ASP.NETMVCSI SThreeArchitecture1（11個(gè)項(xiàng)目）fS00,Entities圄ThreeArchitectuffr.Entitie^E01.DAL卜回ThreeArchitecture.DALEntityFramework回ThreeArchitecture.DALJnterfaceb回ThreeArchitecture.DAL?NHibergte&02.BLLD回ThreeArchitecture.BLLA卜回ThreeArchitecture.BLL.B卜回ThreeArchitecture.BLLInterface，fSgServkeD回ThreeArchitecture.DTOD回ThreeArchitecture.Service《E05.UIP回ThreeArchitecture.UI▲l^]ThreeArchitecture.UI.MVCDAPropertiesP■■引用EiApp^DataDHApp^StartDSiContent關(guān)于具體的代碼，大家可以嘗試新建一個(gè)MVC的應(yīng)用程序，微軟提供的默認(rèn)的MVC的代碼模版中就有相關(guān)的示例代碼，具體的我就不介紹了。Winform的MVC模式厶O(píng)2.AddInClient，&01.Interface上圄iW^.Addln.UI.InterfaceDAPropertiesD■■引用DEControllersDEViews▲E02.Model?畫(huà)WVWAddln.UI.ModelD“PropertiesD引用t>EProfileDc?AddInModel.esJQ03.Controller■圄MBAddln.ULControllerD A* Propertiesb引用t> c? AddInCorrtroller.csD c? AddinEdrtController.esD b AddinSelectController.es丄EO4.View…MddlriViewD4Propertiesr>-■引用bHResourcest>國(guó)AddInEditView.esD圍AddinSelectView.cswinform的MVC模式，主要是通過(guò)事件的方式來(lái)實(shí)現(xiàn)。B、MVP架構(gòu)模式MVP是從經(jīng)典的模式MVC演變而來(lái)，它們的基本思想有相通的地方：Controller/Present負(fù)責(zé)邏輯的處理，Model提供數(shù)據(jù)，View負(fù)責(zé)顯示。作為一種新的模式，MVP與MVC有著一個(gè)重大的區(qū)別：在MVP中View并不直接使用Model，它們之間的通信是通過(guò)Presenter(MVC中的Controlle來(lái)進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會(huì)從直接Model中讀取數(shù)據(jù)而不是通過(guò)Controller在MVC里，View是可以直接訪問(wèn)Model的！從而，View里會(huì)包含Model信息，不可避免的還要包括一些業(yè)務(wù)邏輯。在MVC模型里，更關(guān)注的Model的不變，而同時(shí)有多個(gè)對(duì)Model的不同顯示，及View。所以，在MVC模型里，Model不依賴(lài)于View，但是View是依賴(lài)于Model的。不僅如此，因?yàn)橛幸恍I(yè)務(wù)邏輯在View里實(shí)現(xiàn)了，導(dǎo)致要更改View也是比較困難的，至少那些業(yè)務(wù)邏輯是無(wú)法重用的。1、 View和Model完全解耦，兩者不發(fā)生直接關(guān)聯(lián)，通過(guò)Presenter進(jìn)行通信。2、 Presenter并不是與具體的View耦合，而是和一個(gè)抽象的ViewInterfac耦合，ViewInterfac相當(dāng)于一個(gè)契約，抽象出了對(duì)應(yīng)View應(yīng)實(shí)現(xiàn)的方法。只要實(shí)現(xiàn)了這個(gè)接口，任何View都可以與指定Presenter兼容，從而實(shí)現(xiàn)了PLogic的復(fù)用性和視圖的無(wú)縫替換。3、 View在MVP里應(yīng)該是一個(gè)"極瘦”的概念，最多也只能包含維護(hù)自身狀態(tài)的邏輯，而其它邏輯都應(yīng)實(shí)現(xiàn)在Presenter中?？偟膩?lái)說(shuō)，使用MVP模式可以得到以下兩個(gè)收益：1、 將UI和PLogic兩個(gè)關(guān)注點(diǎn)分離，得到更干凈和單一的代碼結(jié)構(gòu)。2、 實(shí)現(xiàn)了PLogic的復(fù)用以及View的無(wú)縫替換。?E02-WPFP畫(huà)■li.AddlnPlatform-ULWPF.Resources■E01JnfrastructureP畫(huà) AddlnPlatfarrriiUlMPF.InfrestructurewE02*Enterface>畫(huà)||^AddInPlatforn).ULWPF.InterfacedE03*Pre5entert>|S]^MlAddInPiatform.ULWPF.Presenter亠應(yīng)(M.ViewModelD畫(huà)^■^ddlnPlatform-UI-WPF.ViewModel?E09*Add]nClientt>畫(huà)MS?Addin.WPRView展示器層作為核心的控制，實(shí)現(xiàn)view和model之間的完全解耦。關(guān)于該架構(gòu)設(shè)計(jì)的具體demo后面來(lái)介紹C、MVVM架構(gòu)模式MVVM是Model-View-ViewModel的簡(jiǎn)寫(xiě)。微軟的WPF帶來(lái)了新的技術(shù)體驗(yàn)，如Sliverlight音頻、視頻、3D、動(dòng)畫(huà) ，這導(dǎo)致了軟件UI層更加細(xì)節(jié)化、可定制化。同時(shí)，在技術(shù)層面,WPF也帶來(lái)了諸如Binding、DependencyProperty、RoutedEvents、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由來(lái)便是MVP(Model-View-Presenter)模式與WPF結(jié)合的應(yīng)用方式時(shí)發(fā)展演變過(guò)來(lái)的一種新型架構(gòu)框架。它立足于原有MVP框架并且把WPF的新特性揉合進(jìn)去，以應(yīng)對(duì)客戶日益復(fù)雜的需求變化。MVVM模式和MVC模式一樣，主要目的是分離視圖(View)和模型(Model)，有幾大優(yōu)點(diǎn)1?低耦合。視圖(View)可以獨(dú)立于Model變化和修改，一個(gè)ViewModel可以綁定到不同的"View"上，當(dāng)View變化的時(shí)候Model可以不變，當(dāng)Model變化的時(shí)候View也可以不變?？芍赜眯浴Ｄ憧梢园岩恍┮晥D邏輯放在一個(gè)ViewModel里面，讓很多view重用這段視圖邏輯。獨(dú)立開(kāi)發(fā)。開(kāi)發(fā)人員可以專(zhuān)注于業(yè)務(wù)邏輯和數(shù)據(jù)的開(kāi)發(fā)(ViewModel)，設(shè)計(jì)人員可以專(zhuān)注于頁(yè)面設(shè)計(jì)，使用ExpressionBlend可以很容易設(shè)計(jì)界面并生成xaml代碼?？蓽y(cè)試。界面素來(lái)是比較難于測(cè)試的，而現(xiàn)在測(cè)試可以針對(duì)ViewModel來(lái)寫(xiě)。View|DataBindingICommandsMessagesModel視圖(View)視圖負(fù)責(zé)界面和顯示。它通過(guò)DataContext數(shù)據(jù)上下文)和ViewModel進(jìn)行數(shù)據(jù)綁定，不直接與Model交互。可以綁定Behavior/Comand來(lái)調(diào)用ViewModel的方法，Command是View到ViewModel的單向通行，通過(guò)實(shí)現(xiàn)Silverlig提供的IComand接口來(lái)實(shí)現(xiàn)綁定，讓View觸發(fā)事件，ViewModel來(lái)處理事件，以解決事件綁定功能。視圖模型(ViewModel)視圖模型主要包括界面邏輯和模型數(shù)據(jù)封裝，Behavior/Command事件響應(yīng)處理，綁定屬性定義和集合等。它是View和Model的橋梁，是對(duì)Model的抽象，比如：Model中數(shù)據(jù)格式是"年月日”，可以在ViewModel中轉(zhuǎn)換Model的數(shù)據(jù)為“日月年"供View顯示。實(shí)現(xiàn)視圖模型需要實(shí)現(xiàn)Silverlight供的接口INotifyPropertyChangedINotifyPropertyChanged接口用于實(shí)現(xiàn)屬性和集合的變更通知(ChangeNotifications)使得在用戶在視圖上所做的操作都可以實(shí)時(shí)通知到視圖模型，從而讓視圖模型對(duì)象有的模型進(jìn)行正確的業(yè)務(wù)操作。View的代碼隱藏(Code-Behind)部分可能包含界面邏輯或者應(yīng)用邏輯的代碼，這些代碼會(huì)很難進(jìn)行單元測(cè)試，應(yīng)根據(jù)具體情況盡量避免。模型(Model)Model與MVC模式一樣，Model用于封裝與應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)以及