Come si può progettare un'applicazione ASP.Net MVC con EF?

Question

Ho un po 'di problemi a concettualizzare come progettare un'app MVC con Entity Framework in un'app a più livelli.

Il normale, libro di testo App 3 livelli dovrebbe essere simile

dati Access-> Affari logico-> Presentazione

La presentazione non deve sapere nulla circa l'accesso ai dati. Con EF, TUTTI i layer devono conoscere il modello. Quindi la mia architettura ora assomiglia più a

Data Access->Business Logic 
    |    | 
     --------------- 
      | 
      MVC 

Mi manca qualcosa qui o sto pensando a questo nel modo sbagliato?

Dovrei pensare allo stesso EF come livello di accesso ai dati e inserire le entità nella business logic?

Answer 1

Bene, suppongo che la tua domanda sia, come progettare "livelli" nell'applicazione MVC. Dai un'occhiata a questa semplice architettura, io la uso per le mie app MVC e sembra essere pulita ed efficiente.

1. progetto in soluzione - modello di business - semplice libreria di classi completa di classi POCO che rappresentano il dominio aziendale. È possibile utilizzare l'annotazione dei dati qui, le classi di metadati per la logica di convalida, ecc.

2. progetto - repository basati su EF - un'altra libreria di classi semplice; qui è definito contesto (il codice EF prima è ottimo, ma è possibile utilizzare prima il database EF o prima il modello - è sufficiente aggiungere il modello POCO T4 alla libreria di classi del modello di business, non un grosso problema) e un insieme di classi - repository

3. progetto

   - di solito lo chiamo "ServiceLayer" o così (sono aperto al suggerimento per un nome migliore :) - contiene solo interfacce, per repository e altri servizi (implementati in progetti separati) che sarà il mio MVC (o qualsiasi altra tecnologia) uso dell'applicazione basato; repository from 2.project implementare queste interfacce

4. progetto

   - sito MVC. Utilizza l'iniezione delle dipendenze (build in DependencyResolver e mi piace usare il contenitore Ninject) per mappare i repository (e altri servizi); Quindi è possibile utilizzare l'iniezione costruttore in controllori, o qualche approccio "pigro" (vedi sotto)

Sembra qualcosa di simile a questo:

regolatore Magro:

 
public class SomethingController : BaseController 
{ 
    public ActionResult DoSomething(SomeBusinessThing input) 
    { 
     if (ModelState.IsValid) 
     { 
      var result = CustomerRepository.DoSomeBusinessLogicAndPersistenceAndStuff(input); 
      return View(result); // you can use AutoMapper here, if you dont want to use business object as viewmodels 
     } 
    } 
} 

mio repository "proprietà "è ereditato dal mio BaseController:

 
public class BaseController : Controller 
{ 
    // ... other stuff used by all (or multiple) controllers 

    private ICustomerRepository _customerRepository; 
     protected ICustomerRepository CustomerRepository 
     { 
      get 
      { 
       if (_customerRepository== null) 
        _customerRepository= DependencyResolver.Current.GetService(); 
       return _customerRepository; 
      } 
     } 
} 

È possibile utilizzare questo DI" pigro "se il il controller usa molti servizi, ma solo 1-2 per azione, quindi sarebbe inefficiente iniettarli tutti con il costruttore.Qualcuno potrebbe dire che stai "nascondendo" la dipendenza in questo modo, ma se tieni tutte queste cose in un posto - BaseController, non è un grosso problema.

Bene, l'implementazione del repository è davvero il tuo business. applicazione MVC non so nemmeno che si sta utilizzando EF, si conosce solo le interfacce di servizi e non si preoccupa circa underlaying implementazione

Conslusion (che è possibile passare in qualsiasi momento in seguito, se è necessario!):

• I controllori sono magri - nessuna logica aziendale

• Il modello è FAT - e in questo caso i repository racchiudono tutta la logica di business (è possibile utilizzare anche altri tipi di servizi, ad esempio alcuni calcolatori per l'elaborazione, ecc., Ricordare MVC non si preoccupa, lo sa interfacce y)

• ViewModels sono input per Vista (e ViewModel può essere il vostro modello di business direttamente, oppure è possibile utilizzare automapper per la creazione di ViewModels "puri")

Answer 2

È possibile pensare alle entità EF come oggetti dati e disporre di modelli di visualizzazione separati passati nelle viste. I dati degli oggetti EF possono essere utilizzati per popolare i modelli di visualizzazione (qui sono utili librerie come AutoMapper). In questo modo, le tue visualizzazioni non hanno mai una dipendenza diretta sugli oggetti EF, solo sui tuoi modelli di visualizzazione.

Answer 3

ti posso consigliare veramente bene (I pensa) prenota sulla progettazione di architettura basata su domini su piattaforma .NET. Book si chiama guida all'architettura basata su N-Layered Domain con .NET 4.0. Nel libro viene spiegato come creare una buona architettura con EF e MVC (e molte altre cose come Silverlight, IoC con Unity ecc.).

libro può essere scaricato su questo indirizzo:

http://msdn.microsoft.com/es-es/architecture/en/

anche l'applicazione di esempio è molto interessante:

http://microsoftnlayerapp.codeplex.com/

miglior modo per creare entità di EF è la creazione di classi POCO indipendenti sullo strato persistente. Queste entità di dominio sono incluse nel livello logico Dominio (Business).

Nel libro viene anche spiegato che l'applicazione deve essere suddivisa in più livelli, spiegando i livelli di Presentazione, Appliaction, Dominio, Infrastruttura (persistenza dei dati per lo più), Cross-cut e Distributed services.