Comprensione del modo in cui i layer sono separati in un'applicazione MVC

3

Uso Visual Studio 2013 MVC 5 usando Razor.

Voglio capire in quale ordine gli strati siedono e interagiscono tra loro.

Nella mia soluzione ho:

  1. Livello UI (progetto principale) - comprendente modello, vista e controllore
  2. Livello di accesso ai dati (Libreria di classi) - che contiene metodi di stored procedure generici e classe di connessione
  3. Repository (Class Library) - che contiene il codice di accesso ai dati (Crea / Aggiorna / Elimina)
  4. Livello aziendale (Libreria di classi) - che contiene convalide aziendali
  5. Separa livello per REST

Sto preparando il diagramma dell'architettura e voglio capire in che modo i livelli si parlano tra loro.

Presumo che l'ordine sia così:

**Data Access Layer -> Model -> Repository -> Business Layer -> Controller -> View**

Dove si trova REST?

    
posta RPK 11.05.2015 - 11:33
fonte

2 risposte

1

Suppongo che per REST intendi un Web Api di qualche tipo?

questo dovrebbe essere uno strato di interfaccia utente alternativo cioè

DAL - > Repo - > Modello / servizi

- > App MVC

o

- > Web.API

o

- > App per Windows

o

- > App per dispositivi mobili

etc

In alternativa puoi esporre il repository come un livello API (anche se dovrai considerare la sicurezza)

DAL - > Repo - > API RepoService - > RepoClient - > Modelli / BLL (ovvero su un'app mobile con dati Web)

E / O se la tua logica aziendale è composta da servizi che puoi esporre questi

l'idea è di riscrivere il minor numero possibile di codice quando cambi l'interfaccia utente

    
risposta data 11.05.2015 - 11:55
fonte
1

Il primo MVC ha 3 livelli. Modello, vista e controller. Cercando di rendere gli strati BLL o n-Teir in forma non funzionerà molto bene.

M - Modello, questo è il punto in cui "accedi e memorizzi" i tuoi dati.
V - Visualizza, qui è dove esegui il rendering o rappresenti i tuoi dati .
C - Controller, questa è la colla che consente alle viste di dire ai tuoi modelli come / cosa renderizzare tramite le viste.

In una moderna applicazione web, ci sono in realtà diverse applicazioni al lavoro.

Probabilmente il tuo DAL potrebbe essere un'applicazione MVC, i modelli sono tabelle, le visualizzazioni sono l'output delle stored procedure e i controller sono le stored procedure stesse.

"Repository" potrebbe essere un'applicazione MVC in cui il modello è gli oggetti classe che memorizzano i dati dopo il recupero dall'app DAL. Il controller sarebbe quello che mai logica è necessario selezionare ciò che deve tirare dal DAL. E la vista sarebbe, ad esempio, un webservice esposto.

E così via ...

Fondamentalmente, sembrerebbe che il tuo progetto (o la tua comprensione) non stia usando correttamente MVC. MVC non è sempre lo strumento migliore. A volte il buon vecchio n-teir è "migliore".

Un buon esempio di un'applicazione multi-MVC:

Un servizio Web che alimenta un'app mobile e un'app JavaScript / HTML.

Il servizio Web avrebbe il proprio MVC, Modelli costituiti da database / accesso di archiviazione. Le visualizzazioni sono il servizio Web reso json / xml. I controller sono la logica di autenticazione e le convalide sul lato server.

L'app mobile è un'app MVC, i modelli sono le classi che recuperano i dati dal servizio web. I controller sono classi che aiutano a tradurre i dati del servizio Web nelle viste. E le viste sono i file XML (Android) o pennino (iOS) che vengono renderizzati.

L'app JS / HTML avrebbe la stessa struttura dell'app mobile. I Modelli sono la parte che ottiene / e trattiene i dati dai servizi web. I controllori sono le classi che "analizzano" quei dati e le visualizzazioni sono ciò che rende l'HTML in assoluto.

Il problema principale con il tentativo di ottenere n-teir per adattarsi ai termini MVC è che non sono confrontabili, esattamente. La tua logica di business dovrebbe essere in due punti. O controller (se si controllano le cose) o modelli se convalidare le cose. DAO si adatta ai controller (selezionare * dove x = 1) e modelli (CRUD). Le visualizzazioni e l'interfaccia utente sono praticamente le stesse. Ma UI / BLL / DAO non è lo stesso di MVC. Dovresti provare a scegliere una metodologia e usarla invece di cercare di fondere le due cose.

Inoltre, solo per essere sicuri che stessero parlando la stessa cosa l'interfaccia utente non può essere un intero progetto. Presumo che tu abbia un progetto di interfaccia utente che potrebbe essere un'app MVC con i modelli estratti dal progetto DAO.

    
risposta data 11.05.2015 - 15:09
fonte

Leggi altre domande sui tag