oggetto business, sull'oggetto wireframe e sul calcolatore - che è il migliore

Question

Vedo questo schema ancora e ancora e volevo ottenere opinioni:

---

Opzione 1: sull'oggetto filo e sulla composizione dell'oggetto business:

On the wire objec t - i dati che sono serializzati e inviati avanti e indietro attraverso le macchine (client / server, ecc.). Questo è un oggetto POCO.

Ad esempio:

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

Business Objects : un'altra classe che di solito ha alcune o tutte le proprietà come sull'oggetto wire ma anche alcuni campi calcolati. Questo di solito utilizza la composizione in cima a "sul filo". oggetto.

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

---

Opzione 2: sull'oggetto wire e sull'oggetto business per conversazione:

Questo sarebbe lo stesso sull'oggetto wire come nell'esempio 1 ma l'oggetto business, invece di usare la composizione, userebbe le traduzioni:

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

---

Opzione 3: non disporre affatto dell'oggetto business e eseguire tutti i calcoli in una classe di calcolatrice separata. NOTA: i consumatori ottengono l'oggetto sul filo e una calcolatrice

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

Volevo ottenere le opinioni delle persone se ci sono le migliori pratiche o modelli qui o questa è solo una questione di preferenze dell'utente

Answer 1

Nei sistemi a livello aziendale, la mia preferenza è quella di scegliere l'opzione 2. Questo metodo è favorevole allo sviluppo contrattuale in un ambiente SOA e consente agli oggetti del dominio di rimanere indipendenti dalle rappresentazioni dei fili. Facilita le modifiche del contratto nel tempo e consente al dominio e ai contatti dati di cambiare in modo indipendente l'uno dall'altro. Il codice di traduzione può essere un po 'doloroso, ma puoi usare uno strumento come Automapper per accelerarlo.

Detto questo, potresti non richiedere questo livello di flessibilità in ogni app.

Per me l'opzione 3 tende ad andare contro i principi orientati agli oggetti e orientati al dominio perché esternalizza il comportamento, conducendo verso un modello di dominio anemico. L'opzione 1 va anche un po 'contro la progettazione guidata dal dominio perché i tuoi modelli di dominio dipenderebbero dai contratti di dati, quando in realtà dovrebbe essere il contrario. In un modello incentrato sul dominio, tali oggetti di dominio dovrebbero essere indipendenti.