走向.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; }
public string Content { get; set; }
public DateTime CreatedDate { get; set; }
public string CreatedBy { get; set; }
public DateTime UpdatedDate { get; set; }
複制代碼
上面的代碼可以看成類似ORM的映射過程：在Comment類加上Attribute，表明這個屬性和資料表中同名的列對應（在Castle.ActiveRecord架構内部也采用了NHibernate，是以，上面實際上就是NHibernate的映射）。
從上面的一些工作量可以看出，用相應的Frameword來實作blog系統還是比較的快的。而且上面的例子中，業務類和表的結構很一緻，這也是Active Record的特點和優勢。但是如果業務類和資料表的結構不一緻，而且邏輯也變複雜了，也就是出現了“抗阻不比對”。如果還在這中模式上面堅持，會使後面的開始過程和代碼維護變得困難，那麼我們就得采用Domain Model模式來組織業務邏輯。
上面的例子講的很粗糙，因為上面的兩種模式本身還是比較容易了解的，到了Domain Model模式的講解的時候，會更加的詳細。
今天就到這裡了，還是希望多多見諒，支援！謝謝啊！