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

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的wire对象相同，但业务对象（而不是使用合成）将使用翻译：

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也有点反对域驱动设计，因为你的域模型将依赖于数据契约，而实际上应该是相反的。在以域为中心的模型中，这些域对象应该是独立的。