Differenza tra architettura a 3 livelli e MVC (modello, controller di visualizzazione) in ASP.Net

Mi piacerebbe sapere come l'architettura a 3 livelli differisca da MVC (Model, View Controller) in ASP.Net in quanto mi sembra che si applichi la stessa architettura.

In 3-tier che abbiamo User Services Layer, BusinessLayere DataAccessLayer, d'altra parte abbiamo Model, Viewe Controller. Questa mi sembra la stessa architettura.

Qualcuno può spiegare se ciò che differisce davvero delle due architetture, in che modo ogni strato differisce l'uno dall'altro?

È come chiedere quale sia la differenza tra una mela e un nucleo di mela. Queste due architetture non si sostituiscono l'una con l'altra. Penso che una visione più accurata sia che l'architettura a 3 livelli aumenta MVC.

L'architettura MVC

• Modelli: rappresentano "elementi" nella tua applicazione. Questo livello è diventato un po 'sfocato negli ultimi anni, come spiegherò più avanti.

• Visualizzazioni: l'interfaccia utente. La cosa con cui l'utente interagisce.

• Controller: il codice di programmazione che risponde all'utente e alle modifiche nel livello del modello

L'architettura a 3 livelli

Con l'architettura a 3 livelli, hai livelli con responsabilità diverse.

• Servizi per l'utente: (o "servizi" in generale) Questo livello riguarda maggiormente il coordinamento del recupero e delle modifiche del livello "modello". Qui vengono eseguite azioni complesse in più passaggi

• Livello aziendale: rappresenta le regole aziendali incise nel codice di programmazione. Ciò che "The Business" vuole è applicato in questo livello.

• Livello di accesso ai dati: una o più classi responsabili dell'accesso a un archivio dati persistente.

L'unica parte dell'architettura a 3 livelli che si interseca con MVC è il "livello aziendale". I "Modelli" in MVC e il "Livello aziendale" nell'architettura a 3 livelli stanno cercando di raggiungere lo stesso obiettivo.

La "M" in MVC è diventata sfocata

Il livello "modello" in MVC si è ampliato negli ultimi anni. Da quello che ho visto, ci sono due, forse tre tipi di modelli:

1. Modelli di dominio: rappresentano le "cose" a cui interessa "The Business": il dominio aziendale. Queste classi contengono dati e tutte le procedure che operano su tali dati al fine di far rispettare le regole aziendali. Spesso i modelli di dominio sono collegati alle tabelle in un database. Questo sembra adattarsi al "livello aziendale" dell'architettura a 3 livelli.

2. Visualizza modelli: si tratta di classi utilizzate per raggruppare i dati dai modelli di dominio in qualcosa di più appetibile per la vista. Questo non si adatta a nessuna parte dell'architettura a 3 livelli perché i modelli di visualizzazione non implementano la logica aziendale, né forniscono alcun tipo di servizio o accesso ai dati.

3. Modelli di business: in applicazioni complesse, sorge la necessità di separare il modello di dominio dalla logica di business. I modelli di business contengono dati e procedure che operano su tali dati per implementare le regole di business e i modelli di dominio sono relegati in "Borse di proprietà" - oggetti che contengono solo dati ma non contengono alcun comportamento. I modelli di dominio diventano un'altra forma di Data Transfer Object tra il database e l'applicazione.

In nessun punto di MVC viene menzionato l'accesso ai dati. In alcuni casi, vedrai che l'accesso ai dati appartiene al livello "modello" di MVC, che come abbiamo visto non è più un livello chiaro. Vedo davvero che l'architettura a 3 livelli viene accoppiata con MVC per creare un'intera applicazione. Uno aumenta o migliora sull'altro:

• Modelli
  • Modelli di dominio (MVC / 3 livelli)
  • Visualizza modelli (MVC)
  • (facoltativo) Modelli di business (MVC / 3 livelli)
• Visualizzazioni (MVC)
• Controller (MVC)
• Accesso ai dati (3 livelli)
• Servizi (a 3 livelli)

C'è qualche intersezione, ma sono in gran parte separati e insieme vengono utilizzati per disaccoppiare e isolare vari componenti di un sistema più grande.

No, non sono la stessa cosa.

MVC è un modello di progettazione per la strutturazione del codice dell'interfaccia utente. Potrebbe essere utilizzato in un'architettura a tre livelli, nel qual caso il modello appartiene al livello dei servizi utente. Ma può anche essere utilizzato per l'interfaccia utente in un'applicazione che non è a tre livelli, ad esempio una calcolatrice senza persistenza sottostante e quindi senza livello di accesso ai dati.

In un'architettura a tre livelli con un frontend MVC, gli oggetti dominio utilizzati come modello sarebbero gli oggetti del livello aziendale, ma il modello MVC non specifica in realtà che tipo di oggetti è il modello, ma solo quale sia il loro ruolo nel modello è. Ad esempio nella variante MVVM, i modelli sono adattatori specifici dell'interfaccia utente in cima agli oggetti dominio. In questo caso anche il modello appartiene al livello di servizio utente.

So che ci saranno tonnellate di risposte diverse, ma ti darò la mia opinione su questo.

È la risposta più famosa nell'ingegneria del software "Dipende".

Essenzialmente se lo guardi, oltre a varie implementazioni e differenze teoriche, questi sono schemi molto simili con flussi simili.

Dove dipende dipende dall'applicazione che stai creando, una semplice webapp può avere solo un livello MVC che comunica attraverso un ORM con il DB. Uno più complesso può avere MVC che gestisce il front-end nel livello utente, con operazioni esposte non utente più complesse che si verificano nel livello BL, con il livello dati costituito da più origini.