應用程序框架實戰三十八:項目示例VS解決方案的建立(一)

　　進行項目開發的第一步，是建立出適合本身團隊習慣的VS解決方案，雖然我已經提供了項目示例，但畢竟是我建立的，你直接使用可能並不合適，另外你若是嘗試模仿從新建立該示例，中間可能碰到各類障礙，特別是項目間的依賴關係。

　　本文的目的是幫助.Net架構初學者能順利搭建起適合本身的VS解決方案，我會在本文演示曾經用過的幾種不一樣風格的目錄結構，你能夠根據本身的習慣選擇一種並自行修改。

　　本系列假定你已經熟悉如何建立.NET類庫等基礎知識，並具備.Net開發經驗，我不會詳細到每個細節。若是你是.Net初學者，還沒有開發過任何實際項目，對你的建議就是關閉本頁面，去買本書打好基礎，須要提高時再來。

影響VS解決方案結構的因素

分層

　　VS解決方案的建立，與你採用的分層方式密切相關，我在以前的文章已經簡單介紹過單層架構和三層架構，本文采用DDD分層架構進行演示，說明項目示例Applications.Managements是怎樣建立出來的，而且能夠怎樣簡化。

　　咱們平時所說的分層，屬於邏輯分層，它按照必定的邏輯層次分離關注點，以便更好的組織代碼結構，方便維護。

　　物理分層，是將不一樣的代碼部署到不一樣的服務器，以提供更高性能和安全性，若是對邏輯分層和物理分層的關係感興趣，請參考《C#企業應用開發藝術-CSLA.NET框架開發實戰》一書。

　　對於邏輯分層，只要將代碼分離到不一樣區域便可，能夠按照不一樣的抽象粒度來組織代碼，好比類級別、目錄級別、程序集級別。

　　目前廣泛採用的是程序集級別進行分層，即不一樣層的代碼放到不一樣的程序集中。

　　若是指望減小程序集，能夠僅建立一個類庫，採用目錄級別的劃分方式，在一個類庫中建立不一樣層的文件夾，各目錄放置各層的代碼。

　　類級別粒度將不一樣層的對象合併，經過方法的形式分離各層代碼。

　　經過程序集方式分層有諸多好處，好比清晰度、複用性等，我將採用程序集方式進行演示，建議你在項目上也儘可能採用這種方式。

功能模塊

　　另外一個影響VS解決方案建立的因素是功能模塊的劃分。

　　對於一個業務系統，咱們不只要分層，並且還要劃分功能模塊，以便對較大的業務問題進行分解，從而下降複雜度，同時在解決某個特定模塊的問題時，減小其它模塊的干擾。

　　對於領域層，我目前的方式是爲每個功能模塊建立一個類庫項目，這樣作的好處是更方便複用，另外當我須要將這個功能模塊分離出去也會更容易。

　　固然，採用文件夾來分隔也一樣可行，這是兩種不一樣的風格，我會向你演示如何設計能夠更方便的切換。

可複用能力

　　對於一個稍大的項目，把特定業務模塊、通用業務模塊、通用技術類庫放在同一個VS解決方案中，VS解決方案上的項目可能會達到上百個，編譯速度將很是緩慢，致使不少沒必要要的麻煩。

　　我以前已經屢次提到，你能夠把通用技術類和通用業務類從具體項目中分離出來，這樣能夠供多個項目使用，每一個項目擁有本身的VS解決方案，共享相同的應用框架，這樣維護會更容易，編譯速度也更快。  

　　對於Applications.Managements項目示例，通用技術類庫已經抽取到Util解決方案中，Applications.Managements不包含通用性的純技術代碼。

　　我不會爲你演示通用業務類的分離，由於代碼示例太簡單。

其它因素

　　不一樣的應用程序類型也會影響VS解決方案的建立，好比建立WPF智能客戶端應用程序，須要將應用層建立爲WCF類庫，這樣能夠將應用服務直接開放出來供WPF調用。對於WPF+WCF的架構，我後續也會進行介紹，如何經過IOC切換本地調用和遠程調用，經過這個架構能夠在開發時期採用本地方式調用，提升開發效率，部署時切換到WCF遠程代理。

　　若是你採用了諸如SOA架構，須要切割子系統部署成服務，可能須要建立更多類型的項目和多個VS解決方案，這些架構也對VS解決方案的建立具備至關影響。因爲本人在SOA方面經驗尚淺，待後續有更多經驗再進行分享。

VS解決方案建立實戰

　　下面的步驟演示了我建立VS解決方案的習慣，你不必定要按個人步驟，只要最終達到你的要求便可。

建立表現層MVC項目

　　打開VS解決方案，我使用的是VS 2013，自帶了MVC4。

　　建立MVC4項目，項目名稱爲Applications.Presentation.Managements，解決方案名稱爲Applications.Managements，MVC項目模板選擇「基本」。

　　先來討論頂級空間的命名，即這裏的Applications，要點是儘可能抽象。頂級空間名稱儘可能不使用特定於項目或客戶的名稱，由於你作下一個項目時，須要大量更改命名空間。我採用Applications，表明抽象的應用程序，任何項目都是應用程序。你也能夠採用公司的名稱，好比大家公司簡稱爲abc，那麼能夠這樣Abc.Managements。

　　Managements表明這是一個管理系統。Applications.Presentation.Managements說明它是管理系統的表現層，但爲何不用Applications.Managements.Presentation，後面介紹到領域層時我會說明這樣作的緣由。

　　對於表現層來說，沒有其它層會調用它的API，因此我想保持表現層命名空間的簡短，我耍了一個小技巧，將表現層的命名空間改爲了Presentation。

　　右鍵單擊Applications.Presentation.Managements項目，選擇「屬性」，修改「默認命名空間」爲Presetation，以下圖所示。

　　MVC建立完成後，會在根目錄留下一個packages文件夾，MVC項目也會添加packages.config配置，這玩意頗有用，Nuget會幫你管理依賴的程序集及版本，當別人運行你的解決方案時缺乏程序集，會自動下載還原。但我更喜歡本身手工管理，在Applications.Managements根目錄建立Libraries文件夾，我會把packages中必須的幾個dll複製進去，其它所有刪掉。

　　固然，修改表現層默認命名空間和刪除packages屬於個人我的習慣，介紹這個是方便你看個人代碼，對於你本身的項目，徹底不必這麼麻煩。

　　編譯經過，繼續下面的步驟，後面再返回到表現層。

建立表現層擴展項目

　　在Applications.Managements解決方案上右鍵，「添加」->「新建項目」，建立一個類庫項目，名稱爲Applications.Presentation.Managements.Extensions。

　　這個項目用來爲表現層提供一些支持，好比業務組件的封裝。

　　將它的默認命名空間改爲Presentation,方便表現層的調用。

　　下面來考慮類庫輸出的DLL目標位置，默認是在bin\Debug\，表示DLL將輸出到類庫項目的bin目錄下Debug文件夾中。因爲咱們後續會建立更多的程序集，若是對輸出位置不進行統一，將致使每一個輸出目錄都產生大量重複的DLL。

　　右鍵單擊擴展類庫，選擇屬性，找到「生成」選項卡的「輸出路徑「，修改成..\Release\，以下圖所示。

　　下面爲Applications.Presentation.Managements項目添加Applications.Presentation.Managements.Extensions擴展項目的引用。

編譯經過，繼續下面的步驟。 

建立應用層項目

　　在Applications.Managements解決方案上建立類庫項目，名稱爲Applications.Services，修改類庫輸出路徑爲..\Release\。

　　應用層是爲表現層提供服務的，因此表現層Applications.Presentation.Managements須要添加應用層Applications.Services的引用。

　　編譯經過，繼續下面的步驟。

建立基礎設施層項目

　　DDD分層架構中沒有了數據訪問層的概念，被包含到基礎設施層中。

　　基礎設施層是爲其它各層服務的，按道理說，其它各層應該包含對基礎設施層的引用。

　　可是，爲了讓領域層變得更純淨，通常會應用依賴倒置原則，讓基礎設施層反過來依賴領域層。

　　一些初學者會產生疑惑，這樣不是形成循環引用的死循環了嗎？下面談下個人見解，不必定正確，僅供參考。

　　在《領域驅動設計》一書中，對基礎設施層的描述爲：基礎設施層爲各層提供通用的技術能力。

　　可見基礎設施層是一個抽象概念，諸如層超類型、公共操做類的封裝、數據庫的持久化，發郵件，發短信等操做，都是基礎設施層的範疇。

　　在個人代碼中，大量通用技術，都被封裝到Util相關的程序集中，若是須要合併VS解決方案，那麼全部的Util項目都是基礎設施層的一個組成部分。

　　對於領域層與基礎設施層的引用關係，與基礎設施層中項目耦合性強弱有關，通常規律是：

1. 領域層只引用基礎設施層中低耦合的項目，好比領域層能夠引用Util.Core、Util.Domains，這些項目只包含對.NET自己類庫的引用，沒有外部依賴，也不須要任何配置，領域層依賴這些項目不會下降可複用性和可測試性等指標。
2. 與領域層密切相關的高耦合基礎設施層項目，應用依賴倒置原則，先在領域層定義操做接口，由基礎設施層項目引用相關領域層項目，並實現該接口。好比倉儲表明聚合的集合，倉儲的實現依賴於特定數據訪問技術，甚至包含SQL語句，因此具備很高的耦合，且與領域層特定模塊密切相關。若是領域層直接引用數據訪問實現的程序集，將嚴重下降領域層的可複用性，且更難測試。
3. 與領域層關係不大的高耦合基礎設施層項目，應用分離接口模式，將操做接口與具體實現分離到基礎設施層的不一樣項目中。好比工做單元的接口IApplicationUnitOfWork，它與領域層基本沒啥關係，若是你的領域層只包含一個類庫項目，把IApplicationUnitOfWork放到領域層項目中也沒什麼問題，我以前一直是這樣乾的，但若是你的領域層包含多個項目，你應該放到哪個項目中？單首創建一個基礎設施層項目來放置這些接口會好一些。

 

（未完待續…）

代碼更新

1. 更新了js中的一些Bug
2. 因爲項目上須要使用MYSQL，最近幾天摸索了EF操做MYSQL，遇到的一些障礙已解決，特將解決方案放出，供使用MYSQL的同窗參考。

　　　　a) MYSQL的樂觀離線鎖與SQL SERVER顯著不一樣，主要參考王剛的這篇：EF6 Code First 系列 （三）：在MySql中使用和SqlServer一致的RowVersion併發控制。不過對於Sql Server，我仍是使用IsRowVersion，畢竟這是大部分項目的主打。

　　　　b) 經過一個簡單的Ioc配置，便可將Sql Server切換到MySql。

　　c) MySql不支持Sql Server的schema，我使用.分隔MySql表名模擬schema，以保持與Sql Server的一致性風格，這須要一點EF映射技巧。

　　3. codesmith代碼生成模板已更新，調整了命名空間，並增長了對mysql特定配置的生成。

　　4. 數據庫備份中提供了一個MYSQL建庫腳本。

QQ羣

　　應用程序框架交流QQ羣1：386092459（已滿） 

　　應用程序框架交流QQ羣2：376124781 

　　EasyUi交流QQ羣：157809322 

源碼下載：（下載時順手推薦）

框架源碼

項目示例源碼

數據庫備份

Codesmith生成器模板

備註

　　原本準備只用一篇來完成本文，不過太忙了，只有分幾回來寫，但願各位見諒，下次更新的時間會比較長。