2

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

选项 1：关于连线对象和业务对象的组合：

在线对象 - 被序列化并在机器（客户端/服务器等）之间来回发送的数据。这是一个 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：在有线对象和业务对象上通过转换：

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

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

4

1 回答 1

2

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

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

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

于 2009-10-27T13:58:39.847 回答