negócio objeto, no objeto de arame e calculadora - que é melhor

Question

i ver este padrão de uma e outra vez e queria obter opiniões:

---

Opção 1: Na composição de objetos de arame e objeto de negócios:

Sobre o fio objec t - os dados que são serializados e enviados para trás e para frente através de máquinas (cliente / servidor, etc). Este é um objeto POCO.

Por exemplo:

public class Order
{
    public int Price;
    public int Amount;
}

Business Objects - outra classe que geralmente tem algumas ou todas as propriedades como as sobre o objeto de arame, mas também alguns campos calculados. Isso geralmente usa composição em cima do "on the wire" objeto.

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

---

Opção 2: No objeto de arame e objeto de visitas por converstion:

Este seria o mesmo no objeto fio como exemplo 1, mas o objeto de negócios, em vez de usar a composição, usaria traduções:

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

---

Opção 3:. Não tem o objeto de negócios em tudo e ter todos os seus cálculos feito em uma classe calculadora separado NOTA: os consumidores obter o no objeto de arame e uma calculadora

public class Consumer
{
     public void ShowTotal(Order o)
     {
         Calculator calc = new Calculator();
         double total = calc.ShowTotal(o);
      }
}

Eu queria obter opiniões das pessoas sobre se existe uma melhor prática ou padrão aqui ou isso é apenas uma questão de preferência do usuário

Answer 1

Em sistemas de nível empresarial, a minha preferência é ir com a opção 2. Este método é propício para desenvolvimento do contrato-primeira em um ambiente SOA e permite que objetos do seu domínio para permanecer independente das representações de arame. Ele facilita mudanças de contrato ao longo do tempo e permite o domínio e dados de contatos para mudar indepently um do outro. O código de tradução pode ser um pouco de dor, mas você pode usar uma ferramenta como AutoMapper a velocidade que up.

Dito isso, você não pode exigir esse nível de flexibilidade em cada aplicativo.

Para mim opção 3 tendem a ir contra os princípios de orientação a objetos e orientado para o domínio porque ele exterioriza comportamento, conducente a um modelo de domínio anêmico. Opção 1 também vai um pouco contra o domínio driven design, porque seus modelos de domínio seria dependente de contratos de dados, quando, na verdade, que deveria ser o contrário. Em um modelo centrado no domínio, os objetos de domínio deve ser independente.