Dovremmo usare Entity Framework?

Recentemente ho passato dall'utilizzo di query SQL in linea all'utilizzo di EF e ecco quello che ho trovato:

Pro

• Molto più veloce per costruire il DAL (adoro non scrivere le query SQL!)
• Molto più facile da mantenere
• Non è più necessario ricordare di analizzare il mio input prima di creare un'istruzione SQL in linea, il che significa meno possibilità di un attacco SQL injection (ovviamente è ancora possibile a seconda delle query, ma molto meno probabile)

Contro

• Non può estendersi su più database ... almeno non facilmente
• Tutte le entità (tabelle, viste, ecc.) necessitano di una chiave primaria
• Se si desidera aggiornare una singola colonna in una tabella delle colonne di oltre 100 richieste (non la mia tabella design), è necessario tirare giù tutte le 100 colonne per effettuare l'aggiornamento. O utilizzare una stored procedure.
• Ho riscontrato problemi con alcuni valori predefiniti definiti sul server SQL che non venivano inseriti nel modello entità dopo l'aggiunta di un nuovo record. Di solito questo è con valori calcolati, o valori che vengono aggiunti in un trigger INSERT
• A volte, le query SQL vengono scritte male e sono lente da eseguire. Se si dispone di una query a esecuzione ridotta, eseguire una traccia SQL per vedere cosa sta facendo EF. È possibile che tu possa rielaborare quella query come SP o View. Questo però non accade spesso.
• Ho avuto alcuni problemi con il tentativo di creare un'associazione tra tabelle che non hanno una chiave esterna definita in SQL Server. Di solito è perché sto provando a creare una relazione 1:0-1 dove EF vuole usare un 1:0-*

Non sono un esperto di EF, quindi probabilmente mi sono perso alcune cose. Questi sono solo gli elementi che conosco in passato quando passavo da SQL in linea a Entity Framework. Sono contento di aver fatto il passaggio, ma ci sono stati momenti in cui ho davvero odiato EF a causa delle sue stranezze.

Entity Framework è uno strumento di produttività. A meno che tu non abbia una buona ragione per non farlo (sei su SQL 2000 o non hai tempo per utilizzare la tecnologia), utilizza i migliori strumenti a tua disposizione.

Detto questo, trovo il concetto di Entità che si traduce molto bene nel Modello del modello MVC. Anche se avere una relazione 1: 1 con Modelli e tabelle è una cattiva pratica, pensare in termini di Entità tende a produrre disegni puliti, codice di facile lettura (specialmente con LINQ).

Entity Framework è attivamente supportato da Microsoft. Nessuno ha una sfera di cristallo magica per dire "il supporto durerà X anni". Non vedo ragioni per credere che Entity morirà nei prossimi 5 anni.

Un'altra possibile soluzione è utilizzare una libreria di Entity Framework alternativa che non sia quella fornita con V.S. Ce ne sono alcuni là fuori sul web.

Il concetto di struttura Entity / 3 layers, è stato disponibile per un po 'e ha funzionato con diverse librerie personalizzate, come molti altri sviluppatori, prima che Microsoft pubblicasse il proprio framework "ufficiale".

Pro

Avere i vantaggi del framework Entity (D.A.L.), senza essere bloccato con le librerie costanti Microsoft / modifiche al framework.

Aggiunta di funzionalità a una libreria che potrebbero non essere disponibili nella libreria ufficiale esistente, ad esempio l'utilizzo di diverse marche di dtabase.

Contro

Devi supportare la libreria o gli strumenti. È molto comune avere uno strumento per il codice del generatore di entità per generare le eniti.

Devi prendere una decisione architetturale in base al problema e alla soluzione esistente. Come con qualsiasi tecnologia ci sono vantaggi e svantaggi.

Personalmente utilizzerei normalmente il framework entità per il nuovo sviluppo ma non riscrivo il codice esistente funzionante. Ottieni quindi la velocità per il futuro sviluppo, ma non devi investire molto tempo nel convertire il codice. Lo svantaggio di questo approccio è che riduce la coerenza.

Nella tua situazione userò sicuramente Entity Framework, ho trovato che funziona bene con MVC.
Ecco alcuni veri motivi e suggerimenti.

• Linq è un piacere da usare e anche l'esecuzione ritardata è estremamente utile.
• Puoi generare i tuoi modelli (comunque quando usi con mvc ti consiglio di usare i modelli di vista insieme ai modelli di dati, questo rende più facile la validazione e il binding dei modelli, se usi questo approccio usa automapper per mappare le modifiche sul tuo modello dati).

Tuttavia ci sono una serie di cose che devi sapere sull'uso di un ORM.

• Cosa fa il contesto per te (tracciamento dell'entità)
• Che un contesto dovrebbe essere usato come unità di lavoro
• Ricordati di cose sulla concorrenza, EF può dirti quando il tuo oggetto non è aggiornato, ma può essere complicato se vuoi gestire la concorrenza correttamente tra le richieste (dato che devi mantenere un timestamp o qualcosa del genere).

Cose da considerare

• I trigger e gli ORM non funzionano insieme, utilizza invece gli eventi ORM.
• Assicurati che tutte le tue tabelle abbiano le chiavi promemoria.

Raccomando anche il primo approccio al codice, anche se si dispone di un database esistente.

• Le convenzioni indicano che non è necessario rigenerare i mapping o le classi quando si modifica il database.
• È più facile inserire la convalida e l'altra logica nei modelli.
• Puoi utilizzare il generatore di codice per aiutarli a creare un enorme database esistente.