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

Question

я вижу эту картину снова и снова, и хотел бы получить мнение:

---

Вариант 1: На объекте провода и бизнес-объект композиции:

На проводе objec 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: На объекте проволоки и объекта бизнеса по converstion:

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