È necessaria una classe di produzione per la creazione di modelli di visualizzazione?

Un mio collega mi ha suggerito di utilizzare una classe di fabbrica per creare oggetti viewmodel nelle nostre soluzioni ASP.NET MVC. L'idea è che può aiutare con il design e la manutenibilità del modo in cui i modelli di visualizzazione sono integrati nelle nostre app.

Volevo scoprire se qualcun altro ha esperienza di questo. Ho fatto qualche ricerca e ho trovato molto poco su questa pratica.

Attualmente creiamo oggetti viewmodel a livello di controller, ad es

public ActionResult Index()
{
    return this.View(this.BuildIndexViewModel());
}

Quindi this.BuildIndexViewModel () è responsabile della creazione della classe viewmodel (ovviamente :). Ma stiamo esaminando la possibilità di:

public ActionResult Index()
{
    return this.View(ViewModelFactory.CreateIndexViewModel());
}

Questa è un'idea interessante, ma non sono convinto al 100%. Ero interessato alle opinioni di altre persone su questo.

design asp.net-mvc

— Jason Evans
fonte

Faccio fatica a vedere il vantaggio per essere onesti. Useresti una fabbrica per nascondere la costruzione di oggetti, ma perché in questo caso?

— CodeART

Il metodo BuildIndexViewModel è già un metodo factory, presumibilmente privato del controller. L'unico motivo per estrarlo in una classe di fabbrica distinta sarebbe riutilizzarlo in un altro controller.

— MattDavey,

Entrambi condividete i miei stessi pensieri su questo, quindi sono contento di non essere solo :) @MattDavey Posso onestamente dire che dubito fortemente che i modelli saranno usati con più di un controller, il che rende la fabbrica idea ridondante. Lo condividerò quando l'argomento tornerà al lavoro.

— Jason Evans,

Personalmente preferirei che il tipo di modello di vista fosse l'esperto sul processo di costruzione di se stesso. L'unica volta in cui la competenza dovrebbe porsi altrove è se la costruzione richiede la conoscenza di altre aree di applicazione (ad esempio i repository), nel qual caso potresti voler un intermediario per mantenere stupido il modello di visualizzazione :)

— MattDavey,

@MattDavey: puoi racchiudere questi due commenti in una risposta che posso esprimere?

— pdr,

In questo caso, direi che la migliore guida da seguire sarebbero i principi GRASP . In particolare, osserva i quattro criteri di assegnazione della creazione di oggetti:

In generale, una classe B dovrebbe essere responsabile della creazione di istanze di classe A se si applica una, o preferibilmente più, delle seguenti

Le istanze di B contengono o aggregano compositamente le istanze di A
Istanze di B record di A
Le istanze di B usano da vicino le istanze di A
Le istanze di B hanno le informazioni di inizializzazione per le istanze di A e le trasmettono alla creazione.

La classe del controller (B) corrisponde agli articoli n. 3 e n. 4 di tale elenco (e n. 2 se il modello di visualizzazione è POSTO indietro), quindi è già un luogo molto ragionevole in cui vivere il comportamento costruttivo del modello di visualizzazione (A). A mio avviso, ci sarebbero solo due ragioni che mi costringerebbero ad estrarre quel comportamento costruttivo in una classe specialistica.

SECCO - Se due o più controller devono condividere il comportamento di costruzione del modello di vista, incapsularlo in un componente distinto faciliterebbe il riutilizzo del codice ed eviterebbe la duplicazione.
Se il comportamento costruttivo ha dipendenze da altri componenti di sistema come repository, validatori ecc. E non si desidera introdurre questo accoppiamento al controller stesso (in termini GRASP, una pura fabbricazione).

Ripensando a quei 4 criteri di creazione degli oggetti in GRASP, estrarrei il comportamento in una fabbrica separata solo se mi facesse un segno di spunta in più in quella lista. Altrimenti non ci sarebbe alcun valore nel farlo.

Spero possa aiutare!

— MattDavey
fonte