|
代码
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层)”，一般都是基于这种方式在组织逻辑。
这种方式的最大的区别就是每个业务类自己负责自己的数据存取，也就是说在业务类中包含了业务逻辑的处理和数据的存取。
|
