业务对象、在线对象和计算器 - 哪个最好

Question

我一遍又一遍地看到这种模式，并希望获得意见：

---

选项 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：通过转换在连线对象和业务对象上：

在连线对象上，这与示例 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);
      }
}

我想了解人们对是否有最佳实践的意见或此处的模式，或者这只是用户偏好的问题

Answer 1

在企业级系统中，我倾向于选择选项 2。此方法有利于 SOA 环境中的契约优先开发，并允许您的域对象保持独立于线路表示。它有助于随着时间的推移进行合同变更，并允许域和数据联系人彼此独立地进行更改。翻译代码可能有点麻烦，但您可以使用 Automapper 等工具来加快速度。

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

对我来说，选项 3 往往会违背面向对象和领域驱动的原则，因为它将行为外化，导致领域模型贫乏。选项 1 也有点反对领域驱动设计，因为您的领域模型将依赖于数据契约，而实际上应该是相反的。在以领域为中心的模型中，这些领域对象应该是独立的。