业务对象，线对象和计算器上 - 这是最好的

我一遍又一遍的看这个模式，并希望得到的意见：业务对象，线对象和计算器上 - 这是最好的

选项1：在电线对象和业务对象组成：

在线对象 t - 在计算机（客户机/服务器等）之间进行序列化和发送的数据。这是一个POCO对象。

例如：

public class Order 
{ 
    public int Price; 
    public int Amount; 
}

业务对象 - 另一类通常具有一些或所有的属性作为导线对象上，而且一些计算字段的。这通常使用“在线”对象顶部的合成。

public class OrderBusinessObject 
{ 
    private Order _order; 

    public OrderBusinessObject(Order o) 
    { 
      _order = o; 
    } 

    public int Price {return _order.Price;} 
    public int Amount{return _order.Amount;} 
    public int Total{return _order.Price * _order.Amount;}    
}

选项2：在金属丝对象和业务对象通过converstion：

这将是线对象作为实施例1，但在业务对象上是相同的，而不是使用组合物，会用翻译：

public class OrderTranslator 
{ 
    public OrderBusinessObject Translate(Order o) 
    { 
     OrderBusinessObject bo = new OrderBusinessObject(); 
     bo.Amount = o.Amount; 
     bo.Price = o.Price; 
     return bo; 
    } 
} 

public class OrderBusinessObject 
{  
    private int _price; 
    private int _amount; 

    public int Price {return _price;} 
    public int Amount{return _amount;} 
    public int Total{return _price * _amount;}    
}

选项3：根本没有业务对象，并在独立的计算器类中完成所有计算。注：消费者得到的线对象和计算器

public class Consumer 
{ 
    public void ShowTotal(Order o) 
    { 
     Calculator calc = new Calculator(); 
     double total = calc.ShowTotal(o); 
     } 
}

我想获得是否有最好的做法还是这里的图案别人的意见或这仅仅是一个用户偏好

来源

2009-10-25 leora

的事情在企业级系统，我倾向于选择2.这种方法有助于SOA环境中的契约优先开发，并允许域对象保持独立于线表示。它有助于随着时间的推移改变合同，并允许域名和数据联系人相互独立地改变。翻译代码可能有点痛苦，但你可以使用像Automapper这样的工具来加速。

也就是说，你可能不需要每个应用程序都具有这种灵活性。

对我而言，选项3倾向于违背面向对象和领域驱动的原则，因为它将行为外化，导致贫血领域模型。选项1对于领域驱动的设计也有一定的影响，因为您的领域模型将依赖于数据合同，但实际上应该是相反的。在一个以域为中心的模型中，这些域对象应该是独立的。

来源

2009-10-27 13:58:39

业务对象，线对象和计算器上 - 这是最好的

回答

相关问题