3.正确的编写表模块模式、事务脚本模式的代码

这篇文章的重点就是本节，我们将了解一下这两种模式的代码到底该如何编写。

说代码如何编写似乎有点让人觉得不是很礼貌，其实我们大部分的代码写的都是正确的，但是如果我们将有些代码稍微的罗一下位置就会明显不一样。

我们来看一个小例子，例子很简单，有两个类型Order、Product，用来完成一般的业务逻辑处理，我们通过不同的模式来看到底如何使用。

现在的事务脚本模式的代码：

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 <= 20)//不满足条件
                    return;
sendMQOrders.Add(product.PId);//满足条件
            });
MqHelper.SendOrder(orderField, 
sendMQOrders);//发送订单数据实体到队列中
        }
    }
}

Order业务类中有一个添加Order的方法，在该方法中是一些简单的业务逻辑处理，判断了要添加的这个商品的价格是否大于20块钱。最后使用过滤下来的商品ID作为本订单的有效产品。

这就是我们目前使用的代码风格，这里有两个问题，第一：类的命名，Order的概念太大了，没有进行细化，显然不是按照事务脚本模式来进行设计的而是按照表模块方式进行划分的，还有如果我就算你是按照事物脚本模式来设计的，我就喜欢定义大的概念难道不对吗？也可以，但是在Order的定义里面明确使用了Product类型下的子类型，也就说这里出现了两个独立的业务范围，正常的理解肯定是按照表模块模式来设计的。第二：如果是按照表模块模式来设计的，因为根据这个对象的命名很明显是此模式，但是仔细阅读一下代码发现职责还是有点不清晰，在Order.AddOrder(OrderField orderField)方法中，有Product的逻辑在里面if (product.Price <= 20)，当然这里是业务逻辑比较简单的情况下的，如果是业务比较复杂的时候，就会出现大量的代码在Order类中，到最后就会发现我们已经分不清此业务架构到底是使用何种模式来设计的。