Dovremmo usare Entity Framework?

Al momento abbiamo il seguente stack:

• VS 2005
• Moduli Web
• SQL Server 2005
• IIS 6

Stiamo programmando di passare a questo:

• VS 2010
• MVC e Web Form
• SQL Server 2008
• IIS 7

La mia domanda è: quando passiamo a MVC con VS 2010, dovremmo usare Entity Framework (o un altro ORM), un micro ORM (come Massive ) o semplicemente SQL?

Tutti i tutorial che ho letto su VS 2010 sono tutti orientati all'utilizzo di Entity Framework per le transazioni di dati, ma sarà disponibile per il prossimo futuro (oltre 5 anni)?

Se è importante, le applicazioni dei nostri clienti possono avere da 10 a 1.000 utenti attivi.

Di recente sono passato dall'uso di query SQL in linea all'utilizzo di EF ed ecco cosa ho trovato:

Professionisti

• 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 di iniezione SQL (ovviamente, è ancora possibile a seconda delle query, ma molto meno probabile)

Contro

• Impossibile estendere 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 di oltre 100 colonne richieste (non il mio design di tabella), è necessario tirare giù tutte le 100 colonne per effettuare l'aggiornamento. Oppure utilizza una procedura memorizzata.
• Ho avuto 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 hai una query a esecuzione lenta, esegui una traccia SQL per vedere cosa sta facendo EF. È possibile rielaborare la query come SP o Vista. Questo non succede spesso però.
• 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 cercando di creare una 1:0-1relazione in cui EF vuole usare a1:0-*

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

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

Detto questo, trovo che il concetto di Entità si traduca molto bene nel Modello MVC. Pur avendo una relazione 1: 1 con modelli e tabelle è una cattiva pratica, pensare in termini di entità tende a produrre progetti 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 alcun motivo per credere che l'Entità morirà nei prossimi 5 anni.

Un'altra potenziale soluzione è quella di utilizzare una libreria Entity Framework alternativa che non sia quella fornita con VS Ci sono alcuni là fuori sul web.

Il concetto di framework Entity / 3 layer, è in circolazione da un po 'di tempo, e ha lavorato con diverse librerie personalizzate, come molti altri sviluppatori, prima che Microsoft rilasciasse il proprio framework "ufficiale".

Professionisti

Avere i vantaggi del framework Entity (DAL), senza essere bloccato con le costanti modifiche di librerie / framework di Microsoft.

Aggiunta di funzionalità a una libreria che potrebbero non essere disponibili per la libreria ufficiale esistente, come l'utilizzo di diversi marchi dtabase.

Contro

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

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

Personalmente userei normalmente il framework di entità per i nuovi sviluppi ma non riscriverei il funzionamento del codice esistente. Otterrai quindi la velocità per la futura sviluppo ma non dovrai investire molto tempo nella conversione del codice. L'aspetto negativo di questo approccio è che riduce la coerenza.

Nella tua situazione utilizzerei sicuramente Entity Framework, ho scoperto che funziona bene con MVC.
Ecco alcuni motivi e indicazioni reali.

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

Tuttavia, è necessario conoscere alcune cose sull'uso di un ORM.

• Cosa fa il contesto per te (rilevamento delle entità)
• Che un contesto dovrebbe essere usato come unità di lavoro
• Ricorda le 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 (poiché devi mantenere un timestamp o qualcosa del genere).

Cose da considerare

• Trigger e ORM non funzionano insieme, utilizzare invece gli eventi ORM.
• Assicurati che tutti i tuoi tavoli abbiano le chiavi promary.

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

• Le convenzioni indicano che non è necessario rigenerare mappature o classi quando si modifica il database.
• È più desideroso inserire validazione e altra logica nei modelli.
• È possibile utilizzare il generatore di codice per aiutarli a creare un enorme database esistente.