Utilizzo degli oggetti di business nei modelli di vista

10

Quando si utilizzano oggetti di business riutilizzabili, qual è la best practice per la costruzione di modelli di vista?

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

Un costruttore può estrarre i dati attraverso uno o più oggetti aziendali standard per costruire un modello di visualizzazione.

Quale è considerata la pratica migliore quando si tratta di utilizzare oggetti / modelli di business nei modelli di visualizzazione?

Approccio 1

Consenti 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 di 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 c'è un approccio accettato? Nell'approccio 1, non esiste alcuna duplicazione del 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.

    
posta Andy Hunt 02.08.2012 - 17:00
fonte

3 risposte

11

L'opzione 1 crea un accoppiamento stretto tra il modello di dominio e la vista. Ciò è in contrasto con lo stesso problema che i modelli di vista sono stati progettati per risolvere.

Un modello di vista "motivo per cui cambiare" è se la vista stessa cambia. Inserendo un oggetto modello di dominio nel modello di vista, si introduce un'altra ragione per cambiare (ad esempio, il dominio è cambiato). Questa è una chiara indicazione di una violazione del principio di responsabilità unica. Avere due o più motivi per cambiare conduce a visualizzare modelli che richiedono molta manutenzione, probabilmente più del costo di manutenzione percepito della duplicazione attraverso i modelli di dominio / visualizzazione.

Sarei sempre favorevole all'approccio 2. Spesso i modelli di visualizzazione possono sembrare molto simili, persino identici agli oggetti del modello di dominio, ma la distinzione che ho menzionato è la loro diversa motivazione per il cambiamento.

    
risposta data 02.08.2012 - 17:27
fonte
2

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 e la vista stessa. Quel genere di cose è un veleno assoluto per la maintinabilità. YAGNI.

Il punto di avere un modello di vista separato è quello di mantenere lo stato che è significativo solo per la vista (ad esempio, quale scheda è attualmente selezionata) separata dal modello di business. Ma i dati aziendali devono essere riutilizzati anziché duplicati.

    
risposta data 02.08.2012 - 17:53
fonte
2

I principi e i mantra a volte sono preziosi per guidare la progettazione ... ma ecco la mia risposta pratica:

Immagina che i tuoi modelli di vista siano serializzati in JSON o XML. Se provi a serializzare i tuoi modelli di dominio, finirai con un orribile pasticcio di testo e molto probabilmente avrai problemi con riferimenti circolari e altri problemi.

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

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

    
risposta data 02.08.2012 - 17:55
fonte

Leggi altre domande sui tag