|
代碼
public class OrderManager
{
public void PlaceOrder(OrderDTO order)
{
// Validate order based on business rules
// Check for stock availablity on items ordered
// Add the order to the database
// Set the order id on the OrderDTO object
}
public bool CancelOrder(Guid orderId)
{
// Retrieve order from database
// Determine if the order can be canceled
// if order can be canceled, set as canceled
// return true/false if order was canceled
}
public bool AddItemToOrder(Guid orderId, OrderItemDTO ItemToAdd)
{
// Retrieve order from database
// Determine if the item can be added to the order
// Add a new item row in the database
// return true/false if item was added to the order
}
public bool ProcessOrder(Guid orderId)
{
// Check to ensure this order can be processed.
// Validate order based on business rules
// Update the stock levels of products ordered
// return true/false if order was processed
}
}
在上面的代碼中，所有和訂單處理有關的邏輯都寫在OrderManager類中。類中的每一個方法就對應業務邏輯中的一個流程或者說對應一個use case，例如：CancelOrder就是取消訂單。
通過Transaction Script的方式來組織業務邏輯，一個很好的好處就是直觀，很容易理解代碼在做什么。如果有新的流程來了，再加一個方法就行了。
同時，這種組織方式的弊端就在于，當系統中的業務變得多而且復雜的時候，那么這樣的方法就開始變多，最后的結果就是一個類中有成百上千個方法。而且這些方法中，除了一些基本的驗證可以提取為方法重用，其他的流程控制代碼在很多的地方要重寫，特別是當有兩個流程差不多的時候，代碼不可避免的重新寫。于是，這樣的類開始變得龐大而難以管理。
Active Record
這種組織方式已經是我們最熟悉的了。
在很多的項目中，我們的業務實體類基本和數據庫中表是一一對應的，例如一個Order業務類就是代表了數據庫中的Order表。而且在平時項目中，”樸實的三層(N層)”，一般都是基于這種方式在組織邏輯。
這種方式的最大的區別就是每個業務類自己負責自己的數據存取，也就是說在業務類中包含了業務邏輯的處理和數據的存取。
|
