ASP.NET MVC SoC quando si tratta di oggetti back-end (decisione di progettazione)

Question

ASP.NET MVC SoC quando si tratta di oggetti back-end (decisione di progettazione)

#1 da (1 voti)

1

Ho avuto una discussione con alcuni colleghi e anche alcuni lead tecnici nel team intorno a questo e sono tutti per l'approccio purista MVC. Soprattutto quando il progetto si trova nei suoi stadi infantili (è facile implementare un modello che va avanti). Sono fermamente convinto che qualsiasi cosa abbia a che fare con il back-end dovrebbe essere tenuta separata da Views, Models e anche dai View-Models.

È stata presa la decisione finale di utilizzare gli oggetti considerati pass-through perché sono utilizzati ovunque, dall'interfaccia utente fino alla piattaforma back-end che gestisce la richiesta effettiva.

Ecco un esempio di ciò che verrà implementato: MVC stack < - > Piattaforma back-end < - > Puoi parlare con un database o un altro servizio di terze parti E nell'esempio precedente, un oggetto di richiesta back-end può essere realizzato a livello di controller e passato attraverso la piattaforma back-end e lì può essere adattato per soddisfare un database o un altro servizio. E quando il database / servizio di terze parti risponde, la sua risposta viene presa e adattata a uno dei nostri tipi. Questo tipo verrà quindi restituito allo stack MVC. Views e ViewModels utilizzano solo questi tipi di piattaforma back-end.

Quale ID piace vedere fatto: Mi piace che il controllore trasmetta la responsabilità a un adattatore o addirittura a un livello di servizio che è responsabile dell'acquisizione di POCO e della creazione di oggetti della piattaforma di back-end. Crea la richiesta, mandala alla piattaforma back-end. E quando risponde, adatta la risposta in una vista o in un ViewModel e invialo di nuovo al controller. Gli oggetti vengono iniettati nel controller, quindi si tratta semplicemente di passare i POCO a un altro livello per assumersi la responsabilità di creare richieste, inviarle e restituire una risposta costituita da una vista o un ViewModel.

Pro e contro. Con l'attuale implementazione, è conveniente e dato che noi (la mia azienda) possiedono il codice che va dal front-end al back-end che viene utilizzato. Fa risparmiare tempo. Che non abbiamo molto da fare. Non vedo la separazione degli strati qui.

Con l'implementazione che Id desidera vedere, credo che si avvicini un po 'di più al SoC e aggiunga un altro livello di adattamento. Questo è un po 'più di lavoro. E, da un puro punto di vista MVC, usa gli oggetti della piattaforma di back-end che vengono utilizzati nel back-end (sebbene si presumesse che questi oggetti saranno usati anche nel front-end).

Mi rendo conto che è una cosa lunga e che faccio belle foto. Scuse.

Mi piacerebbe sapere cosa avresti fatto. Cin cin.

c# design-patterns asp.net-mvc

posta TheRenoRanger 05.02.2014 - 19:20

fonte

1 risposta

Leggi altre domande sui tag c# design-patterns asp.net-mvc

Memoizzazione memoria Come trasmettere i requisiti di durata?

score 1 · Accepted Answer

Questo è un punto comune di confusione con ASP.NET MVC, principalmente perché MVC è così non-opinato su come deve essere costruita la tua applicazione. @MikeSW è un buon punto: è importante rendersi conto che MVC è un pattern UI , ma, cosa più importante, dovresti capire che è solo un modello . Non è una legge, la struttura non si lamenterà se fai qualcosa di diverso.

Ti dirò come si sviluppa un tipico progetto MVC ASP.NET, perché c'è un motivo per cui è tipico. Hai il livello del dominio. Ciò potrebbe includere un DAL, i servizi, qualunque cosa. Per molti, questo è solo Entity Framework, ma se stai costruendo qualcosa di più grande di un'app ToDo (e forse anche per quello), vorrai svelarlo.

Ora, poiché MVC viene fornito con Entity Framework, l'ipotesi comune è che le entità siano il modello di MVC. Questa è una supposizione molto scarsa. Le entità sono stupide - intenzionalmente stupide. Non sono realmente destinati a scopi diversi dal trasferimento dei dati da e verso il database. Un modello dovrebbe essere l'opposto di quello: dovrebbe contenere tutta la logica aziendale per l'applicazione (o almeno quella parte dell'applicazione. In questo modo, un modello di vista è più vicino al modello di MVC, ma anche allora, non è Direi che il tuo modello è una combinazione del tuo modello di visualizzazione più il tuo livello di dominio. Indipendentemente da ciò, il punto è che se intendi utilizzare le entità come un modello end-to-end, be-all-end-all , ad un certo punto, ti ti morderà nel glorioso massimo. Non è questione di se, ma quando .

La mia raccomandazione è la seguente:

Database -> Entity Framework -> Domain Layer -> Controller -> View Model -> View

E, allo stesso modo.

Il tuo livello di dominio utilizzerà Entity Framework (ma in seguito potrebbe essere sostituito con un'API Web, un servizio WCF, qualunque cosa) per recuperare le tue entità. I tuoi controllori mapperanno le tue entità per visualizzare i modelli e viceversa e le tue visualizzazioni utilizzeranno i tuoi modelli di vista. Per le operazioni POST, i controllori ricevono i modelli di vista, li mappano alle entità e quindi li inviano attraverso il livello del dominio verso il basso per essere creati / aggiornati / qualsiasi cosa. Tutti i grandi progetti MVC sono costruiti in questo modo o in qualche piccola variante di questo, e per una buona ragione: se non lo fai in questo modo ora, dovrai farlo solo in un secondo momento, con molto più tempo e spesa sulla coda.