.NET应用架构设计—表模块模式与事务脚本模式的代码编写(3)

我们有两个做法，第一个做法是：将其改成事务脚本模式，让类的命名和设计泛化，也就是说不要定义那么明显的数据库中的表名字，不要清晰的区分Order和Product两个职责。第二个做法是：将其改成表模块模式，将每个类型中的业务逻辑完全清晰化，将if (product.Price <= 20)提取到Product业务类中去，然后在应用控制器中先处理此逻辑后在调用Order.AddOrder(OrderField orderField)方法进行处理，这个方法里面只做跟当前类型相关的逻辑，参考的依据就是一旦你发现你所写的代码里出现了别的类型时，此时你应该告诉自己有可能这个地方需要重构职责。

两个方法来移动此逻辑：

1：（将if (product.Price <= 20)封进Price属性中）

namespace Business
{
    public class Order
    {
        [Serializable]
        public class OrderField
        {
            public string OId { get; set; }
[NonSerialized]
            public 
List<Product.ProductField> Products { get; set; }
        }
public OrderField Field { get; set; }
public void AddOrder(OrderField orderField)
        {
            var sendMQOrders = new List<string>();//合格的产品ID集合
orderField.Products.ForEach(product =>
            {
                if (product.Price.IsValid()/*执行价格判断*/) return;
sendMQOrders.Add(product.PId);//满足条件
            });
MqHelper.SendOrder(orderField, 
sendMQOrders);//发送订单数据实体到队列中
        }
    }
}

此方法有个问题就是商品的价格没有收到订单的控制，这看具体的业务需要了，我只是个假设。

2：完全独立的过滤无效产品的方法

namespace Business
{
    public class OrderApplicationController
    {
        public void SubmitOrder(Order.OrderField field)
        {
            field.Products = new 
Product().FilterProduct(field.Products);//先过滤
new Order().AddOrder(field);//在添加
        }
    }
}