бизнес-объект, на проводном объекте и калькуляторе - что лучше

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. На проводном объекте и бизнес-объекте по разговору:

Это будет то же самое на объекте wire как в примере 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 также идет вразрез с дизайном, управляемым доменом, потому что ваши доменные модели будут зависеть от контрактов на данные, хотя в действительности это должно быть наоборот. В доменно-ориентированной модели эти доменные объекты должны быть независимыми.