MVC è mai considerato / applicato a livello di sistema?

MVC è diventato una parola di moda che viene applicata a tutto e al lavello della cucina. Se riesci a distinguere una triade con responsabilità diverse e le loro linee di comunicazione non sono tutte sulla mappa, questa verrà etichettata con il termine MVC.

Originariamente, MVC era uno schema per le interfacce utente, in cui la vista era responsabile dell'aggiornamento (porzioni di) dello schermo, il controllore responsabile dell'interpretazione degli eventi di input (originariamente pressione dei tasti e movimento / clic del mouse) e il modello conteneva tutti il resto.

Se si applica questo modello di MVC al sistema a più livelli descritto nella domanda, il livello dell'interfaccia utente conterrà la vista e il controller e i livelli BLL e DAL insieme saranno il modello.

Ma, come ho detto, il termine MVC è stato eroso negli ultimi anni a causa della sua popolarità e altri usi sono sorti.

Dalla mia esperienza, i Controller nascondono tutte le logiche di business che stanno dietro di loro.

Fondamentalmente, quando viene richiesta una pagina, il controllore eseguirà tutte le operazioni logiche di business necessarie, creerà i modelli e li passerà alle viste.

BLL (e DAL dietro di esso) di solito è incapsulato in un progetto / modulo separato e il Controller lavorerà con esso tramite un'API.

I modelli, francamente, non hanno nulla a che fare con il DAL o BLL. Non devono necessariamente essere gli oggetti utilizzati per lavorare con il database e non devono necessariamente essere una "copia" degli schemi di tabelle. In effetti, tale approccio presenta molti inconvenienti, poiché i modelli sono designati per essere utilizzati da visualizzazioni specifiche e i dati necessari per le viste non sono semplicemente un insieme di righe delle tabelle. I modelli possono essere inseriti nello stesso progetto con i Controller.

Questo approccio aiuta a visualizzare l'intero progetto con il pattern MVC. Insieme a ciò, aiuta a creare tutti i livelli familiari (DAL, BLL) senza interrompere il modello.

hai ragione - MVC è un modello che può essere applicato concettualmente come una sorta di architettura a più livelli. M = livello dati, V = livello presentazione, C = livello applicazione. Nessun problema lì. Il livello dati non sa chi consumerà i dati esposti tramite una "API" di stored procedure, né il livello dell'app conoscerà chi consumerà l'API dei servizi Web che espone (ad esempio).

Dove penso che tu ti stia confondendo è perché stai pensando in modalità "framework", dove hai un framework che è organizzato in modo MVC, e ora tutto appare come nel framework framework. ASP.NET MVC è un framework che ti dà un modo di scrivere applicazioni web in un modo particolare, tuttavia, si limita a fare le cose a modo suo e non è un'architettura di sistema completa - i servizi web WCF non fanno parte del suo remit, quindi non li fa. Si potrebbe pensare ad una architettura di sistema molto semplice, una per i principianti prima di progettare sistemi più grandi che sono più disaccoppiati nei livelli. Questo è forse il motivo per cui ci pensi (e quindi MVC nel suo insieme) come qualcosa che si applica efficacemente solo al livello di presentazione.

Ciò significa in pratica è ... niente :) Dovresti continuare la discussione sul pub per ottenere i migliori risultati.

MVC è un ottimo modo per implementare un'interfaccia web perché rende le cose pulite e manutenibili e offre un'utile separazione delle preoccupazioni. Ma in realtà non descrive un intero sistema più di un sistema di interfaccia Windows come WPF o Winforms descrive l'intera applicazione che fornisce il front-end per.

Tuttavia, come ogni modello di progettazione, è anche un modo paradigmatico di guardare al mondo, quindi se vuoi vedere le cose attraverso il filtro di MVC puoi dire che su un'applicazione più grande la View è la tua applicazione framework MVC, la Il controller è il livello del processo aziendale e il modello è il livello ORM o qualsiasi altra origine dati utilizzata. Senza dubbio potresti vedere MVC all'interno di MVC all'interno di MVC a un livello frattale se fosse il modo in cui hai scelto di guardare un'applicazione.

Non è l'unico modo di guardare il mondo, e non è necessariamente utile, ma i modi più diversi di vedere lo stesso sistema più diventa arrotondata la tua comprensione, quindi non è affatto una cattiva idea vedere come interpretare un sistema attraverso diversi paradigmi, specialmente durante le prime fasi di progettazione.

In realtà ho avuto questa discussione con un collega stamattina, nel contesto del nostro software.

Una buona quantità del software MVC di ASP.NET che ho visto sembra essere un po 'confusa riguardo a dove va la logica del business. Non c'è davvero un "livello logico" nel framework. L'approccio più comune sembra essere quello di mettere la logica aziendale nel controller. Questo suggerisce che il modello DA / BL / UI mappa direttamente: DA = Modello, BL = Controller, UI = Visualizza.

Il problema è che spesso ti ritrovi a dover gestire logiche di presentazione più complesse, creando viewmodels che nascondono i dettagli dell'implementazione interna di cui l'utente e l'interfaccia utente non hanno bisogno di sapere e / o racchiudono vari bit di informazioni che la vista avrà bisogno. Se i controller iniziano a gestire molto anche questo, allora i livelli di presentazione e di logica aziendale hanno iniziato a fondersi, che in genere è una cattiva idea. Ci sono modi per mantenere la logica nelle viste (se sei inclinato in quel modo allora usare Knockout rende le tue viste in grado di fare più del lavoro da solo, per esempio) ma in molti casi la logica della presentazione si diffonde. Quello che tendo a fare quando ciò accade è tirare fuori la logica e lasciare che i controllori si concentrino sulla gestione dei viewmodels e delle interazioni dell'utente.

Ora con il Controller View e sotto l'intestazione di "UI", ti rimane l'accesso ai dati e la logica di business che necessitano di case e solo la M di MVC è stata lasciata libera. A questo punto tendo a creare un nuovo livello; un insieme di classi che gestiscono la logica aziendale. Io modellino queste classi sui controller, in quanto ce n'è uno per ogni "area" - spesso uno per modello, ma non sempre. Ad esempio, un web store semplice potrebbe avere una ProductsController di gestione delle pagine di elenchi di prodotti e un ProductsManager corrispondente che gestisce la logica di business attorno agli oggetti Product . Qualsiasi controller può utilizzare ProductsManager se necessario, ma la maggior parte delle cose che sarà necessario saranno probabilmente in ProductsController .

Come ti riferisci a questo è un argomento che può essere discusso (ed è stato, un bel po '). Si riduce a considerare se queste classi del livello logico siano parte del modello, e ciò dipende principalmente da cosa intendi per "modello". Se pensate che la parola "modello" significhi "una rappresentazione di un'entità (o di un sistema)", allora queste classi a livello logico hanno più probabilità di essere qualcos'altro, e avete trasformato MVC in MLVC o qualcosa (che è bene). Se pensi a "modello" come a "rappresentazione di un'entità o di un sistema e al suo comportamento ", allora sì, queste classi a livello logico fanno parte del tuo modello, formando il "comportamento del sistema" "parte mentre le tue classi di entità fanno il resto. Si può sostenere che quest'ultimo è più corretto, o almeno più vicino alla definizione di "modello" che viene comunemente utilizzato da persone come gli analisti di sistema.

Fai attenzione a non applicare modelli di design in generale liberamente. Gli schemi di progettazione hanno lo scopo di semplificare o chiarire lo scopo del design e creare una migliore organizzazione. Gli schemi di progettazione non dovrebbero essere considerati un goto al posto di una programmazione corretta e ben pensata.