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

【问题标题】：business object, on the wire object and calculator - which is best业务对象，在线对象和计算器 - 这是最好的
【发布时间】：2009-10-25 17:50:52
【问题描述】：

我一遍又一遍地看到这种模式并想得到意见：

方案一：关于有线对象和业务对象的组合：

在线对象t - 被序列化并在机器（客户端/服务器等）之间来回发送的数据。这是一个 POCO 对象。

例如：

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

Business Objects - 另一个类，通常具有部分或全部属性作为在线对象，但也有一些计算字段。这通常在“在线”对象之上使用合成。

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：在wire对象和Business对象上通过转换：

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

我想就这里是否有最佳实践或模式或者这只是用户偏好问题征求人们的意见

【问题讨论】：

标签： c# design-patterns poco data-transfer-objects

【解决方案1】：

在企业级系统中，我更喜欢使用选项 2。这种方法有利于 SOA 环境中的合同优先开发，并允许您的域对象保持独立于线路表示。它促进了合同随时间的变化，并允许域和数据联系人相互独立地更改。翻译代码可能有点麻烦，但您可以使用 Automapper 之类的工具来加快速度。

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

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

【讨论】：