Utilisation d'objets métier dans les modèles de vue

Lors de l'utilisation d'objets métier réutilisables, quelle est la meilleure pratique lors de la création de modèles de vue?

Nous utilisons un objet que nous appelons Builderpour construire nos modèles de vue. Un générateur pour chaque unité logique de vues (commandes, utilisateurs, etc.), où chaque unité peut contenir un certain nombre de modèles de vue différents (les commandes contiennent un résumé, des lignes de commande, etc.).

Un générateur peut extraire des données via un ou plusieurs objets métier standard afin de créer un modèle de vue.

Qu'est-ce qui est considéré comme la meilleure pratique lorsqu'il s'agit d'utiliser des objets / modèles métier dans les modèles de vue?

Approche 1

Autoriser l'utilisation d'objets métier dans le modèle de vue?

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary();
        obModel.Order = obOrder;

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public Some.Business.Logic.Order Order;
    //Other methods for additional logic based on the order
    //and other properties
}

Approche 2

Prendre uniquement les données nécessaires des objets métier

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary()
        {
            OrderNum = obOrder.OrderNum,
            NumOrderLnes = obOrder.NumOrderLines,
        }

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public int OrderNum;
    public int NumOrderLines
    //Other methods for additional logic based on the order
    //and other properties
}

Je peux voir les avantages et les inconvénients des deux, mais je me demande s'il y a une approche acceptée? Dans l'approche 1, il n'y a pas de duplication de code autour des modèles, mais cela crée une dépendance à la logique métier. Dans l'approche 2, vous prenez uniquement les données nécessaires à la vue, mais vous dupliquez le code autour des modèles.

L'option 1 crée un couplage étroit entre le modèle de domaine et la vue. Cela va à l'encontre des modèles de vue très difficiles à résoudre.

Une vue modélise la «raison de changer» si la vue elle-même change. En plaçant un objet de modèle de domaine dans le modèle de vue, vous introduisez une autre raison de changer (par exemple, le domaine a changé). Il s'agit d'une indication claire d'une violation du principe de responsabilité unique. Le fait d'avoir deux raisons ou plus de changer conduit à des modèles de vue qui nécessitent beaucoup de maintenance - probablement plus que le coût de maintenance perçu de la duplication entre les modèles de domaine / vue.

Je préconiserais toujours l'approche 2. Il est souvent vrai que les modèles de vue peuvent sembler très similaires, voire identiques aux objets de modèle de domaine, mais la distinction, comme je l'ai mentionné, est leurs différentes raisons de changement.

L'option 1 est préférable car elle évite la duplication de code. C'est ça.

Si le modèle de domaine change de manière significative, il est presque certain que la vue devra de toute façon changer. Avec l'option 2, vous devez alors changer le modèle de vue ET le générateur ainsi que la vue elle-même. Ce genre de chose est un poison absolu pour la maintenabilité. YAGNI.

Le point d'avoir un modèle de vue séparé est de garder un état qui n'a de sens que pour la vue (par exemple quel onglet est actuellement sélectionné) séparé du modèle commercial. Mais les données d'entreprise elles-mêmes devraient être réutilisées plutôt que dupliquées.

Les principes et les mantras sont parfois précieux pour guider la conception ... mais voici ma réponse pratique:

Imaginez que vos modèles de vue soient sérialisés en JSON ou XML. Si vous essayez de sérialiser vos modèles de domaine, vous allez vous retrouver avec un désordre hideux de texte et très probablement rencontrer des problèmes avec les références circulaires et d'autres problèmes.

Le but d'un modèle de vue n'est pas de regrouper des modèles de domaine afin que la vue puisse les consommer. Au lieu de cela, le modèle de vue devrait être un modèle complètement plat de la vue ... la chose réelle que vous regardez à l'écran. Votre logique de vue ne doit concerner que la structuration des données présentes dans le modèle de vue.

Idéalement, votre modèle de vue doit être composé presque entièrement de chaînes pré-formatées. Pensez-y ... vous ne voulez même pas de date ou d'heure décimale dans votre modèle de vue, car vous êtes coincé à faire une logique de formatage en C #, Javascript, Objective-C, etc.