Esiste la necessità di una classe factory per la creazione di modelmodelli?

Question

Esiste la necessità di una classe factory per la creazione di modelmodelli?

#1 da (7 voti)

16

Un mio collega ha suggerito di utilizzare una classe factory per la creazione di oggetti viewmodel nelle nostre soluzioni ASP.NET MVC. L'idea è che può aiutare con la progettazione e la manutenibilità del modo in cui i modellini di vista sono costruiti nelle nostre app.

Volevo scoprire se qualcun altro ha esperienza di questo. Ho fatto delle ricerche 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 ne sono convinto al 100%. Ero interessato alle opinioni di altre persone su questo.

design asp.net-mvc

posta Jason Evans 23.04.2012 - 21:51

fonte

1 risposta

Leggi altre domande sui tag design asp.net-mvc

Quanto dovrebbe essere granulare un comando in un modello CQ [R] S? Cos'è un buon repository di sorgenti leggere per lo sviluppo locale? [chiuso]

score 7 · Accepted Answer

In questo caso, direi che la migliore guida da seguire sarebbe i principi GRASP . In particolare, guarda i quattro criteri di assegnazione della creazione dell'oggetto:

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

Le istanze di B contengono o aggregano composte istanze di A
Istanze di istanze di record B di A
Le istanze di B utilizzano da vicino le istanze di A
Le istanze di B hanno le informazioni di inizializzazione per le istanze di A e le passano alla creazione.

La tua classe controller (B) corrisponde agli elementi # 3 e amp; # 4 di quella lista (e # 2 se il viewmodel viene POSTATO indietro), quindi è già un posto molto sensato per il comportamento della costruzione viewmodel (A) da vivere. Per come la vedo, ci sarebbero solo due ragioni che mi spingono ad estrarre quel comportamento di costruzione in una classe specialistica.

DRY - Se due o più controllori devono condividere il comportamento di costruzione viewmodel, incapsularlo in un componente distinto faciliterebbe il codice riutilizzare ed evitare la duplicazione.
Se il comportamento di costruzione 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).

Guardando indietro a quei 4 criteri di creazione di oggetti in GRASP, vorrei solo estrarre il comportamento in una fabbrica separata se mi ha guadagnato un segno di spunta in più in quella lista. Altrimenti non ci sarebbe alcun valore nel farlo.

Spero che ti aiuti!