Utilizzo di oggetti business nei modelli di visualizzazione

Quando si utilizzano oggetti business riutilizzabili, quali sono le migliori pratiche per la creazione di modelli di vista?

Usiamo un oggetto che chiamiamo Builderper costruire i nostri modelli di vista. Un costruttore per ogni unità logica di viste (ordini, utenti, ecc.), In cui ciascuna unità può contenere un numero di diversi modelli di vista (gli ordini contengono un riepilogo, righe ordine ecc.).

Un builder può estrarre i dati attraverso uno o più oggetti business standard al fine di costruire un modello di vista.

Qual è la pratica migliore quando si tratta di utilizzare oggetti / modelli di business nei modelli di vista?

Approccio 1

Consentire l'uso di oggetti business nel modello di visualizzazione?

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

Approccio 2

Prendi solo i dati necessari dagli oggetti business

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

Posso vedere i vantaggi e gli svantaggi di entrambi, ma mi chiedo se esiste un approccio accettato? Nell'approccio 1, non c'è duplicazione di codice attorno ai modelli, ma crea una dipendenza dalla logica aziendale. Nell'approccio 2, si prendono solo i dati necessari per la vista, ma si duplica il codice attorno ai modelli.

L'opzione 1 crea un accoppiamento stretto tra il modello di dominio e la vista. Ciò è in contrasto con i problemi di visualizzazione dei modelli progettati per risolvere.

Una "ragione per cambiare" dei modelli di vista è se la vista stessa cambia. Inserendo un oggetto modello di dominio nel modello di visualizzazione, si introduce un altro motivo per cambiare (ad es. Il dominio è cambiato). Questa è una chiara indicazione di una violazione del principio della responsabilità singola. Avere due o più motivi per cambiare porta a visualizzare modelli che richiedono molta manutenzione, probabilmente più del costo di manutenzione percepito della duplicazione tra modelli dominio / vista.

Suggerirei sempre l'approccio 2. Spesso i modelli di vista possono apparire molto simili, anche identici agli oggetti del modello di dominio, ma la distinzione, come ho già detto, è la diversa ragione del cambiamento.

L'opzione 1 è preferibile in quanto evita la duplicazione del codice. Questo è tutto.

Se il modello di dominio cambia in modo significativo, è quasi certo che la vista dovrà comunque cambiare. Con l'opzione 2, è necessario modificare il modello di vista E il builder nonché la vista stessa. Questo genere di cose è un veleno assoluto per la manutenzione. YAGNI.

Il punto di avere un modello di vista separato è mantenere lo stato significativo solo per la vista (ad es. Quale scheda è attualmente selezionata) separata dal modello di business. Ma i dati aziendali stessi dovrebbero essere riutilizzati piuttosto che duplicati.

I principi e i mantra sono talvolta preziosi per guidare il design ... ma ecco la mia risposta pratica:

Immagina che i tuoi modelli di visualizzazione vengano serializzati in JSON o XML. Se provi a serializzare i tuoi modelli di dominio, finirai con un orribile disordine di testo e molto probabilmente incontrerai problemi con riferimenti circolari e altri problemi.

Lo scopo di un modello di visualizzazione non è di raggruppare i modelli di dominio in modo che la vista possa utilizzarli. Invece il modello di vista dovrebbe essere un modello completamente piatto della vista ... la cosa reale che stai guardando sullo schermo. La logica della vista dovrebbe riguardare solo la strutturazione dei dati presenti nel modello di vista.

Idealmente, il modello di visualizzazione dovrebbe essere composto quasi interamente da stringhe preformattate. Pensaci ... non vuoi nemmeno un DateTime o un decimale nel tuo modello di vista perché poi sei bloccato a fare la logica di formattazione in C #, Javascript, Objective-C, ecc.