走向.NET架構設計—第四章—業務層分層架構（前篇） 　　前言：在任何一個項目中業務層毫無疑問是最重要的層，所以在設計的過程中，如何組織業務層是至關重要的。本章的討論將會涉及Flower的架構模式一書中的四種組織業務層的模式：Transaction Sript,Active Record,Anemic Model 和Domain Model。每一中組織業務邏輯的模式有著各自都優缺點，如何選擇他們重要的還是取決于我們所要開發的項目的類型。 在討論完四種模式之后，我將會和大家一起來看看DDD的一些知識。 每種模式的講解，我都會用實例的形式給出完整的代碼，也希望大家多琢磨！ 本篇議題如下： Transaction Scrip(前篇) Active Record前篇) Domain Model（中篇） Anemic Model（中篇） DDD（后篇） 　 ? 　　不是所有的應用程序都是一樣的，也不是所有的系統都需要用復雜的架構來組織業務邏輯。作為開發人員，我們必須清楚每一種業務邏輯組織的模式，這樣我們才能在需要的時候做出合適的選擇。 ? 　　Transaction Script 這種組織業務邏輯的模式是最簡單，也是最容易理解的。Transaction Script模式就是用面向過程的方式來組織業務邏輯的。通常情況下，系統的一個流程就被實現為一個方法，然后把所有的這些方法組織在一起，放在一個靜態的manager類或者service 類中。實現流程的那個方法包含了業務邏輯的Check和Validation，數據的持久化以及其他的一些相關操作。也就是說，一個方法把所有的事情都做完了。當然，有時候這個大的方法還可能被拆成小的方法，便于重用。 ? Transaction Script一個好處就是理解起來很簡單，尤其是當Team中的一個新成員來說，更是如此，因為他幾乎不用花什么時間，就能立刻明白這種組織業務邏輯的方式。每當來了一個新的需求的時候，要做的事情就是去加上一個或者一些新的方法來是實現這個需求，而其還不會影響其他已經存在的功能。 ? 對于一個很小的或者基本山沒什么業務邏輯的系統來說，用Transaction Script模式組織業務邏輯還是很不錯的，而且對一個剛剛踏入IT的開發人員門檻也比較低。：當系統開始變大，業務邏輯開始變得復雜的時候Transaction Script的問題的出來了。最后的結果可能就是系統中存在大量的方法，而且這些方法中到處都是重復的代碼。有的時候，我們可以提煉出一些業務邏輯的驗證代碼組織為方法，但是我們去很難提煉出一些在流程上相識的代碼，即使兩個流程只有一點點的不同。如果系統的需求稍微一邊，導致流程變了一點點，那么很多的方法就要改動，而且我們還得在系統中去找出那些相似的流程代碼，然后修改，萬一哪個方法沒有找出，后果可想而知。 ? 下面我們就用一個人事請假管理系統為例子來看看Transaction Script是如何實現的。因為Transaction Script很簡單，所以下面的代碼也只是用于演示，大家理解就行了。 ? 代碼 public?class?HolidayService
{
??????public?static?bool?BookHolidayFor(int?employeeId,?DateTime?From,?DateTime?To)
??????{
??????????bool?booked?=?false;
??????????TimeSpan?numberOfDaysRequestedForHoliday?=?To?-?From;
??????????if?(numberOfDaysRequestedForHoliday.Days?>?0)
????????????{
??????????????if?(RequestHolidayDoesNotClashWithExistingHoliday(employeeId,?From,?To))
????????????????{
????????????????????int?holidayAvailable?=?GetHolidayRemainingFor(employeeId);
????????????????????if?(holidayAvailable?>=?numberOfDaysRequestedForHoliday.Days)
????????????????????{
????????????????????????SubmitHolidayBookingFor(employeeId,?From,?To);
????????????????????????booked?=?true;
????????????????????}
????????????????}
????????????}
????????????return?booked;
????????}

????????private?static?int?GetHolidayRemainingFor(int?employeeId)
????????{
????????????//?...
????????}

????????public?static?List<EmployeeDTO>?GetAllEmployeesOnLeaveBetween(
????????DateTime?From,?DateTime?To)
????????{
????????????//?...
????????}

????????public?static?List<EmployeeDTO>?GetAllEmployeesWithHolidayRemaining()
????????{
????????????//?...
????????}
????} ? ? ???????? 一眼看上去，我們就很容易理解這種面向過程的方式：系統中的所有的用例都被組織成了一個個的方法。例如在BookHolidayFor方法中就做了很多的事情：查詢和持久化數據，是否允許請教的業務邏輯的實現等。 ???????? 如果在一個很簡單的，業務很少的系統中采用這種方式還是可以的，隨著業務邏輯的越來越復雜，我們就得重新考慮下這種組織邏輯的方式，越早發現，越早做出改變，以后的成本將會越小。 ? 　　Active Record ???????? 下面就以一個內容管理系統中的文章管理功能為例來講述如何使用活動記錄模式來組織業務邏輯。相信大家對內容管理管理系統（CMS）都有一些了解，對于文章模塊，用戶可以發布文章，游客或其他用戶可以發表評論。在相應的數據庫中，存在著文章表tb_Articles和評論表tb_Comments， ??????? ? 在Active Record模式中，每一個業務對象各自負責自己的數據持久化邏輯和相關的業務邏輯。正如前面提到的：Active Record模式很適合那種“業務對象和數據表一 一對應”的簡單的應用程序，例如Blog，Forum等系統。因為在Active Record模式中，每一個業務類和表都有對應的關系，而且業務類都包含了CRUD的操作，那么我們可以使用一些代碼生成工具來加速我們的開發，而且有些好的代碼生成工具還包含了一些數據庫的邏輯驗證代碼來確保我們把正確的數據保存到數據庫中。 ? ???????? 下面我們就用一個例子來看看這種模式是如何應用的。例子還是采用之前談到的CMS Blog系統。 ????? 在業務層，業務類Article和Comment的結構如圖所示 ? ??? 在Active Record模式中，每一個業務對象各自負責自己的數據持久化邏輯和相關的業務邏輯。 ????正如前面提到的：Active Record模式很適合“業務對象和數據表一一對應”的應用程序，例如Blog、Forum等系統；同時Active Record模式也比較適合“數據為先”的應用程序：根據現有的數據庫來組織邏輯和建立業務模型。 ? ???? 因為在Active Record模式中，每一個業務類和表都有對應的關系，而且業務類都包含了CRUD的操作，我們可以使用一些代碼生成工具來加速開發，而且有些好的代碼生成工具還包含了一些數據庫的邏輯驗證代碼，以確保我們把正確的數據保存到數據庫中。例如，在.NET中，可以直接使用Castle 的Active Record Framework來快速開發應用程序。 ???? 下面就使用Castle ActiveRecord框架來開發上面的文章管理模塊 ? ?[ActiveRecord("tb_Comments")]
????public?class?Comment?:?ActiveRecordBase<Comment>
????{
????????[PrimaryKey]
????????public?int?Id?{?get;?set;?}

????????[BelongsTo("ArticleID")]
????????public?Article?Post?{?get;?set;?}

????????[Property]
????????public?string?Subject?{?get;?set;?}

????????[Property]
????????public?string?Content?{?get;?set;?}

????????[Property]
????????public?DateTime?CreatedDate?{?get;?set;?}

????????[Property]
????????public?string?CreatedBy?{?get;?set;?}

????????[Property]
????????public?DateTime?UpdatedDate?{?get;?set;?}
????} 復制代碼 ??? 上面的代碼可以看成類似ORM的映射過程：在Comment類加上Attribute，表明這個屬性和數據表中同名的列對應（在Castle.ActiveRecord框架內部也采用了NHibernate，所以，上面實際上就是NHibernate的映射）。???????? ? 從上面的一些工作量可以看出，用相應的Frameword來實現blog系統還是比較的快的。而且上面的例子中，業務類和表的結構很一致，這也是Active Record的特點和優勢。但是如果業務類和數據表的結構不一致，而且邏輯也變復雜了，也就是出現了“抗阻不匹配”。如果還在這中模式上面堅持，會使后面的開始過程和代碼維護變得困難，那么我們就得采用Domain Model模式來組織業務邏輯。 ? 上面的例子講的很粗糙，因為上面的兩種模式本身還是比較容易理解的，到了Domain Model模式的講解的時候，會更加的詳細。 ? 今天就到這里了，還是希望多多見諒，支持！謝謝啊！

轉載于:https://blog.51cto.com/yanyangtian/413312

總結

以上是生活随笔為你收集整理的走向.NET架构设计—第四章—业务层分层架构（前篇）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。