I vincoli degli attributi sono l'ultimo dei tuoi problemi. I modelli EF non sono oggetti POCO , sono entità DTO strettamente interconnesse allo schema del tuo database e DbContext / DbSet s.
C'è un'enorme quantità di logica invisibile in agguato dietro quelle proprietà di get e set dall'aspetto innocente; loro (le entità DTO) fanno tutti i tipi di cose magiche "EF", come ad esempio:
- Traduci le tue query da LINQ a entità in SQL
- Gestisci il caricamento lento
- I modelli EF sono anche legati in
EntityState per DbContext
Sfortunatamente, molte esercitazioni ASP.NET su MVC sono state introdotte nei controller. Quei tutorial ti insegnano una cattiva abitudine che ti morderà non appena proverai a fare qualcosa di non banale
Ad esempio, immagina di avere un modello EF Employee , che ha anche un metodo in esso chiamato GetManager() .
Vedi questo bit di LINQ, sembra innocente vero?
var managers = from emp in MyDbContext.Employees
where emp.Department == "Sales"
select emp.GetManager();
se MyDbContext.Employees fosse qualcosa di semplice come un List<Employee> dove Employee è un POCO regolare, questo andrebbe bene. ma sfortunatamente la suddetta query genererà un'eccezione perché tenta di convertire emp.GetManager() in un'istruzione SQL - eccetto che non esiste qualcosa come GetManager in SQL ...
Un altro problema: se possiedi proprietà lazy-loaded che tenti di utilizzare dopo DbContext.Dispose() , ti troverai a dover caricare forzatamente la proprietà prima di eliminarla (e ricorda di impostare anche EntityState.Detached ), o eseguendo tutta la tua logica aziendale all'interno del tuo blocco using .
Naturalmente, potrebbe essere ok se hai una logica di business molto semplice a cui interessano solo alcune semplici entità di database; è necessario mantenere la prospettiva e ricordare che KISS è anche importante.
Tuttavia, è ragionevole aspettarsi che tu possa anche prendere alcuni dati da un'altra fonte, come un file, un servizio di rete, un'altra API o altro database, ecc. La logica aziendale che si verifica all'interno di un blocco EF using è un percorso comune al debito tecnico e al codice difficile da mantenere.
Naturalmente, tutte queste sono cose che puoi "aggirare", ma è probabile che il risultato significhi combinare tutta la tua logica dell'interfaccia utente con la tua logica aziendale e di livello dati; la separazione delle preoccupazioni dell'interfaccia utente rispetto alle problematiche del database diventa scomoda quando si utilizzano modelli EF in Controller .
Quindi, stai molto attento quando decidi di utilizzare i modelli EF direttamente nei tuoi controller MVC perché qualsiasi cosa marginalmente non banale può vederti combattere tutti i tipi di eccezioni lanciate da EF che non vedresti in modelli POCO mappati regolarmente. Il prezzo da pagare per la quantità nominale di codice boilerplate che mappa dai tuoi modelli EF ai tuoi modelli di 'Business Layer' è molto ragionevole, rispetto al terribile debito tecnico con cui potresti finire in altro modo.