|
代碼
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
}
}
在上面的代碼中，所有和訂單處理有關(guān)的邏輯都寫在OrderManager類中。類中的每一個方法就對應(yīng)業(yè)務(wù)邏輯中的一個流程或者說對應(yīng)一個use case，例如：CancelOrder就是取消訂單。
通過Transaction Script的方式來組織業(yè)務(wù)邏輯，一個很好的好處就是直觀，很容易理解代碼在做什么。如果有新的流程來了，再加一個方法就行了。
同時，這種組織方式的弊端就在于，當系統(tǒng)中的業(yè)務(wù)變得多而且復(fù)雜的時候，那么這樣的方法就開始變多，最后的結(jié)果就是一個類中有成百上千個方法。而且這些方法中，除了一些基本的驗證可以提取為方法重用，其他的流程控制代碼在很多的地方要重寫，特別是當有兩個流程差不多的時候，代碼不可避免的重新寫。于是，這樣的類開始變得龐大而難以管理。
Active Record
這種組織方式已經(jīng)是我們最熟悉的了。
在很多的項目中，我們的業(yè)務(wù)實體類基本和數(shù)據(jù)庫中表是一一對應(yīng)的，例如一個Order業(yè)務(wù)類就是代表了數(shù)據(jù)庫中的Order表。而且在平時項目中，”樸實的三層(N層)”，一般都是基于這種方式在組織邏輯。
這種方式的最大的區(qū)別就是每個業(yè)務(wù)類自己負責自己的數(shù)據(jù)存取，也就是說在業(yè)務(wù)類中包含了業(yè)務(wù)邏輯的處理和數(shù)據(jù)的存取。
|
