asp.net架构设计解惑（二）
2010-9-27编辑:dan
代码
| 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层）”，一般都是基于这种方式在组织逻辑。
这种方式的最大的区别就是每个业务类自己负责自己的数据存取，也就是说在业务类中包含了业务逻辑的处理和数据的存取。