ASP.NET MVC4 Architettura n-Tier: approccio migliore

Question

Sviluppo di un'architettura a 3 livelli per una webapp MVC4 + EntityFramwork5. Voglio mantenere separato il livello, quindi solo DAL sa che sto usando EF, per esempio.

In realtà ho un sacco di classi per la gestione che:

DAL

1. entità POCO
2. Entity DataContext: DbContext
3. Entity Repository

BL

1. Entity ViewModel
2. Entity servizi (istanziare Entity Repository)

WEB

1. entità Controller (un'istanza di entità di servizio)

Questo è il lavoro ma è abbastanza difficile da mantenere. Stavo pensando di rimuovere l'Entity Repository in DAL e utilizzare direttamente DataContext (se non sbaglio, dopotutto DbContext è stato designato come Repository e Unit of Work), ma questo mi costringerà ad aggiungere un riferimento a EntityFramework.dll nel mio BL. Non è un grosso problema, ma non sono sicuro che sia la scelta migliore.

Qualche consiglio?

(spero ho dato sufficienti informazioni, se avete bisogno di più, basta chiedere)

Answer 1

È possibile utilizzare thisthis e this articolo.

An experienced Architect does not need to go through every single step in the book to get a reasonable design done for a small web 

applicazione. Tali architetti possono utilizzare la loro esperienza per accelerare il processo . Poiché ho già fatto applicazioni web simili e ho compreso il mio deliverable con , ho intenzione di adottare l'approccio più rapido a per ottenere la parte iniziale del nostro progetto DMS. Spero che mi aiuti ad abbreviare la lunghezza di questo articolo.

For those who do not have experience, let me briefly mention the general steps that involved in architecturing a software below... 

Understand the initial customer requirement - Ask questions and do research to further elaborate the requirement 
Define the process flow of the system preferably in visual (diagram) form. I usually draw a process-flow diagram here. In my 

sforzo, vorrei cercare di definire la versione manuale del sistema prima e poi avrebbe cercato di convertire in versione automatizzata mentre individuando i processi e le loro relazioni. Questo diagramma di flusso di processo che disegniamo qui può essere utilizzato come supporto per convalidare i requisiti acquisiti anche con il cliente. Identificare il modello di sviluppo software che soddisfa i requisiti Quando i requisiti sono completamente acquisiti e definiti prima dell'inizio del progetto, è possibile utilizzare il modello "Water-Fall".Ma quando i requisiti non sono definiti, è possibile utilizzare una variante di "Spirale" per gestire con quello. Quando i requisiti non sono definiti, il sistema viene definito mentre è in fase di progettazione. In questi casi, è necessario mantenere gli spazi adeguati nei rispettivi moduli, che in seguito sono previste espansioni. Decidi quale architettura utilizzare. Nel mio caso, per progettare il nostro sistema di gestione dei documenti (DMS), userò una combinazione di ASP.NET MVC e Multitier Architecture (Three Tier Variant). Analizza il sistema e identifica i suoi moduli o sottosistemi.
Selezionare un sottosistema alla volta e analizzarlo ulteriormente e identificare tutti i requisiti a livello granulare appartenenti a quella parte dei sistemi. Riconoscere le entità dati e definire le relazioni tra entità (Diagramma di relazioni entità o Diagramma ER). Questo può seguito dall'individuazione delle entità aziendali (Alcune entità aziendali si mappano direttamente con le classi del sistema) e definiscono il flusso del processo aziendale . Organizzate le vostre entità. Qui è dove normalizzi il tuo database e decidi quali concetti OOP e modello di progettazione devono essere usati ecc.
Rendi coerente la tua progettazione. Segui gli stessi standard su tutti i moduli e livelli. Ciò include la semplificazione dei concetti (come esempio , se sono stati utilizzati due diversi modelli di progettazione in due moduli diversi per ottenere lo stesso obiettivo, quindi scegliere l'approccio migliore e utilizzarlo in entrambe le posizioni) e le convenzioni utilizzate nel progetto. La sintonizzazione del design è l'ultima parte del processo. Per fare ciò, è necessario avere un incontro con il team di progetto. In quella riunione di devi presentare il tuo progetto al tuo team e fargli chiedere le domande allo . Prendi questo come un'opportunità per valutare onestamente/ adattare il tuo design.