Devo utilizzare Entity Framework, DataSet o Classi personalizzate?

Question

Sto attraversando un periodo difficile. Devo progettare una "app per desktop" che utilizzi WCF come canale di comunicazione. È un'applicazione multi-livello (DB e application server sono gli stessi, il client passa attraverso Internet Cloud).

L'applicazione è un po 'complessa (in termini di logiche SQL e di codice) quindi le solite applicazioni LOB, ma il concetto è lo stesso: lettura da DB, aggiornamento a DB, gestione della concorrenza ecc. Il mio problema è che ora con Entity Framework in chiaro, non posso decidere in che modo procedere: dovrei usare Entity Framework, Dataset o Custom Classes.

Come ho capito da Entity Framework, creerà la mappatura degli oggetti delle mie tabelle DB anche con gli script CRUD. Questo è tutto bene per CRUD semplice, ma la maggior parte delle volte il "Seleziona" è complesso e richiede un SQL personalizzato. Capisco che posso usare Stored Procedures in EF (non mi piace SP btw, non so perché, mi piace codificare il mio SQL nel DAL a mano, mi sento più sicuro e comodo in quel modo).

Con DataSet, userò i miei SQL personalizzati e compilerò il set di dati. Con le classi personalizzate (oggetti per le tabelle DB) popolerò i miei SQL personalizzati su quelle classi personalizzate (raccolte ed elenchi, ecc.). Voglio usare EF, ma non mi sento fiducioso nella distribuzione di un'applicazione la cui SQL non ho scritto e non posso vedere nel codice. Mi sto perdendo qualcosa qui.

Qualsiasi aiuto in questo senso sarebbe molto apprezzato.

Xeshu

Answer 1

Sono d'accordo con Marc G. 100% - DataSet fa schifo, specialmente in uno scenario WCF (aggiungono un sacco di overhead per la gestione della manipolazione dei dati in memoria) - non li uso. Va bene per i principianti e le applicazioni desktop a due livelli su piccola scala forse - ma non li userei in un'app professionale e seria.

Fondamentalmente, la tua domanda si riduce a come trasformare le tue righe dal database in qualcosa che puoi remoto attraverso WCF. Questo significa una qualche forma di mappatura - o fai tu stesso, usando DataReader e poi spingi tutti i dati nelle classi WCF [DataContract] - puoi certamente farlo, ti dà il controllo definitivo, ma è anche noioso, ingombrante e soggetto a errori.

Oppure lasciate che qualche ORM pronto gestisca questo lavoro per voi: scegliete tra Linq-to-SQL (ottimo, facile da usare, flessibile, ma solo SQL Server), EF v4 (out by Marzo 2010 - sembra molto promettente, molto flessibile) o qualsiasi altro ORM, in realtà - qualunque sia il meglio per le tue esigenze.

Altri concorrenti seri nello spazio ORM potrebbero includere Subsonic 3.0 e NHibernate (tra molti molti altri).

Quindi per riassumere:

• dimenticare Dataset
• o si ha il controllo al 100% e per il mapping tra SQL e gli oggetti da soli
• si lascia un po 'in grado di gestire ORM che (Linq- to-SQL, EF v4, Subsonic, NHibernate et al) - che è davvero una questione di preferenze personali e stile di codifica

Answer 2

Non posso sostenere i set di dati, soprattutto in un ambiente SOA come WCF - sarà il lavoro, ma per lo più le ragioni sbagliate. Semplicemente non sono portabili e l'IMO in realtà non "funziona" oltre i limiti del servizio. Naturalmente, IMO non funzionano anche nella maggior parte degli altri scenari ;-p

Quindi, quindi, si tratta di quanto idraulico si vuole fare. La maggior parte degli ORM creerà per te tipi serializzabili WCF; personalmente Al momento userei LINQ-to-SQL; è più semplice e completo di EF, sebbene l'EF 4.0 sia destinato ad essere molto meglio di EF in 3.5sp1. È possibile utilizzare TSQL personalizzato (tramite ExecuteQuery, che esegue ancora il mapping agli oggetti), ma io tendo a utilizzare SPROC (per query complesse) o query generate da LINQ (per richieste semplici).

Scrivere i tipi da soli va bene, e funzionerà con NHibernate ecc. Tante opzioni.

Answer 3

Mentre EF lavora con WCF e così via e molto promettente, dovresti prendere in considerazione lo sforzo di accelerare. Soprattutto quando si fa qualcosa di non banale, il progettista in VS2008 non può più aprire il modello e si deve codificare il modello in xml.

Inoltre, tenere presente che EF funziona su un livello di astrazione molto elevato. A causa del law of leaky abstractions non è tutto così lucido come dovrebbe essere :) In alternativa, ciò significa che devi gestire istruzioni SQL molto pazze e difficili da leggere inviate al tuo database quando si tratta di problemi di risoluzione dei problemi/prestazioni.