Le migliori pratiche attuali di Microsoft per la creazione di un livello dati .NET? E la realtà?

Il team di sviluppo con cui sto lavorando si trasferirà presto a .NET 4.0, tuttavia, la libreria di classi di accesso ai dati che utilizziamo utilizza ancora "classico" ADO.NET, che significa SqlDataReader , DataTable e simili. Nel frattempo, sembra che Microsoft e probabilmente il resto del mondo stiano andando avanti con Entity Framework e WCF Data Services . Non ho trovato nulla su MSDN che indica quale delle tecnologie di accesso ai dati Microsoft considera le migliori pratiche.

Microsoft ha una preferenza? Quali accessi ai dati utilizzano attualmente la maggior parte delle persone? Ci sono buoni motivi per rimanere con ADO.NET classic e non passare a Entity Framework?

Nella mia azienda stiamo usando l'EF. È un bel ORM, adatto per il nostro piccolo progetto. In realtà le persone usano EF o NHibernate. Entrambi i framework sono buoni. EF ha un ottimo supporto MS e puoi trovare ottimi strumenti in bundle con Visual Studio. NHibernate è considerato migliore di EF ma esiste una "curva di apprendimento" più ampia, quindi passerai più tempo ad adottarla.

Penso che, se sei su Ado.Net "classico", prova EF. Crea un semplice progetto e sostituisci alcuni dei metodi DAL. Controlla come funziona e come puoi gestire / modificare il codice. Confrontalo con i semplici metodi "SqlDataReader" e decidi quale è meglio. Ricorda che ogni cambiamento tecnologico ha bisogno di un po 'di tempo per essere adottato, quindi devi calcolare se questo cambiamento sarà vantaggioso per la tua azienda nel lungo periodo.

La mia squadra sta trovando la realtà del passaggio a EF un po 'un dolore. Non è perché EF è dannoso o non utile, ma l'ambito della conversione dei nostri livelli di dati esistenti (abbastanza massicci) da set di dati fortemente tipizzati provenienti da ADO.Net Framework 2.0 su EF è solo un lavoro intenso che non guadagna davvero noi qualunque cosa. Per le nuove cose siamo ancora abbastanza lacerati perché tutti abbiamo opinioni e obiettivi. Per i nostri progetti Silverlight, ci stiamo concentrando esclusivamente sui servizi EF e RIA, ma per i progetti web (moduli web e MVC 3) utilizziamo principalmente Linq2Sql.

Stiamo riscontrando meno mal di testa e uno sviluppo più rapido utilizzando Linq2Sql, ma so che Microsoft sta promuovendo l'agenda EF (in particolare con i servizi WCF e RIA). Linq2Sql non andrà da nessuna parte, ma tutti i nuovi giocattoli e le fantastiche funzionalità saranno focalizzati su EF. Direi che se avessi una scelta in anticipo, EF sarebbe un buon punto di partenza. Se sei già a metà flusso, non so che sarà molto facile passare.

Entity Framework è la strada da percorrere preferita. LinqToSql sarà supportato e mantenuto, ma l'attenzione allo sviluppo in futuro è su Entity Framework. Scegli tra ADO.NET Entity Framework e LINQ to SQL