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

2

Я вижу этот шаблон снова и снова и хотел получить мнения:


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

На проводной objec 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, но бизнес-объект вместо использования композиции будет использовать переводы:

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);
      }
}

Я хотел получить мнение людей, если здесь есть лучшая практика или образец, или это только вопрос предпочтений пользователя

Теги:
design-patterns
poco

1 ответ

2
Лучший ответ

В системах уровня предприятия я предпочитаю использовать вариант 2. Этот метод способствует разработке контрактов в среде SOA и позволяет вашим объектам домена оставаться независимыми от проводных представлений. Это облегчает изменение контрактов с течением времени и позволяет доменным и информационным контактам меняться независимо друг от друга. Код перевода может быть немного больным, но вы можете использовать инструмент, например Automapper, чтобы ускорить его.

Тем не менее, вы можете не требовать такого уровня гибкости в каждом приложении.

Мне вариант 3 будет идти против объектно-ориентированных и основанных на доменах принципов, поскольку он вытесняет поведение, приводящее к модели анемической области. Вариант 1 также немного противоречит дизайну, основанному на домене, потому что ваши модели домена будут зависеть от контрактов с данными, когда на самом деле это должно быть наоборот. В центральной модели домена эти объекты домена должны быть независимыми.

Сообщество Overcoder
Наверх
Меню