objet métier, sur l'objet de fil et calculatrice - qui est le mieux

Question

je vois ce schéma encore et encore et je voulais obtenir des avis:

---

Option 1: Sur la composition objet métallique et objet métier:

Sur le fil Objec t - les données qui sont sérialisées et renvoyées sur les machines (client/serveur, etc.). C'est un objet POCO.

Par exemple:

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

Business Objects - une autre classe qui a généralement une partie ou toutes les propriétés que les sur l'objet métallique, mais aussi des champs calculés. Cela utilise généralement la composition au-dessus de l'objet "sur le fil".

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

---

Option 2: Sur l'objet métallique et objet métier par converstion:

Ce serait la même sur l'objet métallique comme par exemple 1, mais l'objet métier, au lieu d'utiliser la composition , utiliserait les traductions:

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

---

Option 3: N'ayez pas du tout l'objet métier et faites tous vos calculs dans une classe de calculatrice séparée. NOTE: Les consommateurs obtiennent le sur l'objet métallique et une calculatrice

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

Je voulais obtenir l'opinion des gens sur s'il y a une meilleure pratique ou un motif ici ou bien cela est juste une question de préférence de l'utilisateur

Answer 1

Dans Pour les systèmes au niveau de l'entreprise, ma préférence va à l'option 2. Cette méthode est propice au développement d'un contrat dans un environnement SOA et permet aux objets de votre domaine de rester indépendants des représentations par câble. Il facilite les changements de contrat au fil du temps et permet aux contacts de domaine et de données de changer indépendamment l'un de l'autre. Le code de traduction peut être un peu douloureux, mais vous pouvez utiliser un outil comme Automapper pour accélérer cela. Cela dit, vous pourriez ne pas avoir besoin de ce niveau de flexibilité dans chaque application. Pour moi, l'option 3 aurait tendance à aller à l'encontre des principes axés sur les objets et les domaines, car elle externalise le comportement, conduisant à un modèle de domaine anémique. L'option 1 va également un peu à l'encontre de la conception pilotée par domaine car vos modèles de domaine dépendraient des contrats de données, alors que ce devrait être l'inverse. Dans un modèle centré sur un domaine, ces objets de domaine doivent être indépendants.