Come creare MVC Views che funzionano con la progettazione del modello di dominio polimorfico?

0

Questo è più un tipo di domanda "come lo faresti".

L'applicazione su cui sto lavorando è un'app MV.NET di ASP.NET che utilizza la sintassi del rasoio.

Ho un bel modello di dominio che ha alcune classi polimorfiche, fantastiche con cui lavorare nel codice, ma ho alcune domande riguardo il front-end MVC.

Le viste sono facili da costruire per le classi normali, ma quando si tratta di quelle polimorfiche sono bloccato nel decidere come implementarle.

L'unica (brutta) opzione è quella di costruire una pagina che gestisce il tipo di base (ad esempio IContract) e ha una serie di istruzioni if per verificare se abbiamo passato in un'istanza IServiceContract o ISupplyContract. Non bello e molto cattivo da mantenere.

L'altra opzione è di costruire una vista per ciascuna di queste classi child di IContract, rompendo completamente i principi di DRY. Non mi piace farlo per ovvi motivi.

Un'altra opzione (anche non eccezionale) è dividere la vista in blocchi con partial e creare viste parziali per ogni tipo di bambino che viene caricato nella vista principale per il tipo di base, quindi decidere di mostrare o nascondere il partial in una singola affermazione nel parziale. Anche disordinato.

Ho anche pensato di creare una pagina master con sezioni per i campi che si verificano solo nelle sottoclassi e per creare viste per ciascuna sottoclasse che fa riferimento alla pagina principale. Questa sembra la soluzione meno problematica? Consentirà una manutenzione abbastanza semplice e non implica la duplicazione del codice.

Quali sono i tuoi pensieri? Mi manca qualcosa di ovvio che renderà le nostre vite più facili? Suggerimenti?

    
posta Johann 13.09.2012 - 08:13
fonte

3 risposte

1

In realtà, la creazione di viste individuali per ciascuna delle classi IContract non violerebbe DRY - presumibilmente hanno alcune informazioni diverse con esigenze diverse. Non stai ripetendo te stesso, stai usando polimorphisim con successo.

Ho avuto un parallelismo un po 'simile per un progetto MVC1 - prima che DisplayFor fornisse una soluzione integrata piuttosto buona. Abbiamo utilizzato i delegati RenderAction di MVC Contrib per inviare l'oggetto polimorfico a un controller specializzato che era responsabile della distribuzione di elementi alla pipeline di rendering appropriata. Gli interni diventano un po 'stridenti, ma per noi è stato un sistema solido per almeno 3 anni.

    
risposta data 13.09.2012 - 18:35
fonte
0

La soluzione che abbiamo usato, laddove appropriato, è utilizzare DisplayFor e EditFor

Abbiamo strongmente scritto display e modelli di modifica in modo che la vista di base sia una semplice, semplice, pulita iterazione su un elenco di elementi ei modelli gestiscono il polimorfismo.

Si può discutere sull'idoneità di costruire viste su modelli di dominio - ma ciò non elimina il requisito di poter visualizzare un elenco di elementi che sono notoriamente uguali (hanno una radice comune) ma variano in dettaglio e nel caso in cui abbiamo risolto questo problema in modo molto preciso senza dover inserire alcuna logica nella vista

    
risposta data 13.09.2012 - 17:59
fonte
0

Penso che la tua opzione più pratica sia solo per verificare il sapore di IContract con cui hai a che fare e quindi estrarre il markup personalizzato in partial che contengono il markup specifico per quell'oggetto del modello. In questo modo la vista principale gestisce l'output di markup generico di IContract e i partial hanno i dettagli di WhateverContract personalizzati.

Scrivo solo viste complete separate se gli oggetti fossero così diversi da dove ci sarebbe poca o nessuna ripetizione del markup. È meglio avere alcuni if / els nella tua vista principale piuttosto che dover aggiornare più viste quando è necessario apportare una modifica.

    
risposta data 13.09.2012 - 20:13
fonte

Leggi altre domande sui tag