Se un'applicazione ASP.NET MVC utilizza direttamente Entity Framework come modello?

21

Sto costruendo la mia prima applicazione MVC in Visual Studio 2013 (MVC 5) e sono un po 'confuso sul modo migliore per configurare il mio modello.

Ho generato un modello di framework di entità utilizzando il codice prima da un database esistente. Il mio primo istinto è stato quello di creare alcune classi intermedie che sarebbero state il modello utilizzato dalle viste e far sì che quelle classi lavorassero con le classi del framework di entità.

Mentre stavo scrivendo i corsi di intermediario mi sono reso conto che stavo solo ri-implementando molte delle cose che le classi EF già facevano solo con occasionali setter privati o cast da un tipo di dati all'altro. Sembrava uno spreco.

La regola generale è di utilizzare direttamente le classi del framework entità come Modello per un'applicazione MVC? O c'è qualche vantaggio che mi manca per la costruzione di queste classi intermedie?

    
posta Mike D. 29.09.2014 - 06:39
fonte

2 risposte

22

Nelle mie applicazioni ho sempre separato le cose, con diversi modelli per il database (Entity Framework) e MVC. Li ho separati anche in diversi progetti:

  • Esempio.Entità : contiene le mie entità per EF e il contesto DB per accedervi.
  • Example.Models - contiene modelli MVC.
  • Example.Web - applicazione web. Dipende da Example.Domain e Example.Models.

Invece di conservare riferimenti ad altri oggetti come fanno le entità di dominio, i modelli MVC conservano gli ID come numeri interi.

Quando arriva una richiesta GET per una pagina, il controller MVC esegue la query del database, che restituisce un'entità. Ho scritto i metodi "Convertitore" che accettano un'entità di dominio e la convertono in un modello MVC. Esistono altri metodi che fanno l'opposto (da un modello MVC a un'entità di dominio). Il modello viene quindi passato alla vista e quindi al client.

Quando arriva una richiesta POST, il controller MVC ottiene un modello MVC. Un metodo di conversione lo converte in un'entità di dominio. Questo metodo esegue anche eventuali convalide che non possono essere espresse come attributi e si assicura che se l'entità di dominio esiste già che la stiamo aggiornando piuttosto che ottenerne una nuova. I metodi di solito assomigliano a questo:

public class PersonConverter
{
    public MyDatabaseContext _db;

    public PersonEntity Convert(PersonModel source)
    {
         PersonEntity destination = _db.People.Find(source.ID);

         if(destination == null)
             destination = new PersonEntity();

         destination.Name = source.Name;
         destination.Organisation = _db.Organisations.Find(source.OrganisationID);
         //etc

         return destination;
    }

    public PersonModel Convert(PersonEntity source)
    {
         PersonModel destination = new PersonModel()
         {
             Name = source.Name,
             OrganisationID = source.Organisation.ID,
             //etc
         };

         return destination;
    }
}

Usando questi metodi prendo la duplicazione che altrimenti accadrebbe in ogni controller. L'uso di generici può deduplicare ulteriormente le cose.

Il fare cose in questo modo offre molteplici vantaggi:

  • È possibile personalizzare un modello per una vista o un'azione specifica. Supponiamo che tu abbia un modulo di iscrizione per una persona che, una volta inviata, crei molte entità diverse (persona, organizzazione, indirizzo). Senza modelli MVC separati questo sarà molto difficile.
  • Se devo passare più informazioni alla vista che altrimenti sarebbero disponibili solo nell'entità, o combinare due entità in un singolo modello, i miei preziosi modelli di database non vengono mai toccati.
  • Se serializzi un modello MVC come JSON o XML, ottieni solo il modello immediato serializzato, non tutte le altre entità collegate a questa.
risposta data 29.09.2014 - 09:14
fonte
6

Direi che dipende molto dalla tua applicazione. Sta semplicemente facendo puro CRUD, senza alcuna logica di business? Quindi utilizzerei i modelli EF direttamente nelle mie visualizzazioni.

La maggior parte delle volte è coinvolta almeno una logica aziendale e quindi uno strato tra i dati / modelli EF e la vista potrebbe essere una buona idea. In questo caso potrebbe essere opportuno fare "CQRS-lite" (vedi sotto) e usare diversi modelli dentro e fuori dal tuo controller. Il più delle volte i modelli di lettura sono molto più "grassi" dei modelli di scrittura ...

Tuttavia, se l'applicazione contiene molte logiche di business e / o ha bisogno di scalare molto, implementerei almeno il nucleo di esso utilizzando CQRS (Command Query Responsibility Segregation), DDD (Domain Driven Design) ed Event Event Reperimento. Quindi EF può essere usato come facciata del modello di lettura.

Ricorda inoltre che non è necessario attenersi a una strategia / modello per l'intera applicazione, alcune aree potrebbero essere CRUD pure e altre aree potrebbero contenere molte logiche di business ...

    
risposta data 02.10.2014 - 23:47
fonte

Leggi altre domande sui tag