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

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

2 голосов
/ 25 октября 2009

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

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

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

Это будет то же самое на объекте 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);
      }
}

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

1 Ответ

2 голосов
/ 27 октября 2009

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

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

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

...