Sembra che ci siano molte strategie di accesso ai dati diverse provenienti da Microsoft. Esistono "classiche" ADO.NET, Linq2Sql, ADO.NET Entity Framework, ADO.NET Data Services, ADO.NET Dynamic Data. Sono sicuro di averne perso qualcuno. Per me, sembra che ci sia molta confusione intorno a dove ogni framework si adatta all'architettura di un'applicazione. Che problema sta cercando di risolvere Microsoft con tutti questi metodi di accesso ai dati?Che problema sta cercando di risolvere Microsoft con tutte queste strategie di accesso ai dati?
risposta
Stanno cercando di risolvere il problema di come aumentare le vendite e la quota di mercato. A tal fine, vari gruppi all'interno di Microsoft cercano di attaccare il problema di come ottenere più sviluppatori e utenti finali che utilizzano i loro prodotti. Gruppi diversi hanno tecnologie diverse e, come qualsiasi altra grande azienda, Microsoft lotta per mantenere le sue tecnologie allineate e gruppi che lavorano allo stesso fine. Inoltre, con l'arrivo delle nuove tecnologie, è necessario mantenere (o meglio ancora, impostare) il ritmo e continuare a supportare le tecnologie obsolete in cui i loro clienti hanno investito. Il risultato finale per qualsiasi tipo di azienda ragionevolmente grande, inclusa Microsoft, è una selezione un po 'confusa di selezioni tecnologiche.
MS non è mai stato bravo con le tecnologie DB: vedi ODBC, OLEDB, ADO, RDO, DAO, Jet ... ce ne sono troppi da elencare. – gbjbaanb
La confusione è la nostra frustrazione. Molti di noi che prendono queste decisioni di architettura per i nostri siti web hanno sollevato le nostre mani con la mancanza di chiarezza di Microsoft e le buone pratiche di sviluppo su questo problema.
La mia squadra è stata sicuramente masterizzata da Linq2Sql.
Ora costruiamo il nostro sito Web con un approccio di Domain Driven Design e in particolare l'architettura di cipolla di Palermo (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/). Gli oggetti business sono solo POCO e non hanno dipendenze sull'infrastruttura.
L'infrastruttura è ora gestita da NHibernate e un ORM laminato personalizzato per il nostro CMS. I dolorosi costi di avvio per questi sono stati di gran lunga superati dalla consapevolezza che la comunità continuerà a spostare NHibernate nella direzione migliore e controlleremo la fonte del nostro ORM. Peggio ancora, e Microsoft rilascia qualcosa di davvero avvincente che funziona in un'architettura DDD, abbiamo solo bisogno di riscrivere il nostro livello di infrastruttura.
Non vedo il punto di questa domanda. In effetti, è un po 'trollare.
- ADO.NET è la tecnologia di accesso ai dati originale di .NET 1.0. Chiaramente non appartiene a nessuna discussione sulle nuove "strategie" di accesso ai dati
- LINQ to SQL è uno dei provider LINQ originali. Fornisce una mappatura uno-a-uno tra le strutture del database e i tipi utilizzati in un programma. Doveva funzionare con SQL Server
- ADO.NET Entity Framework è più flessibile. Doveva funzionare con qualsiasi provider ADO.NET e ha un livello di mappatura, in modo che il programma funzioni con classi più vicine alle entità di business che alle tabelle di database. Ad esempio, una singola entità può includere dati da più tabelle. Microsoft ha deciso di dedicare più impegno all'EF che a LINQ su SQL.
- ADO.NET Data Services è un livello di servizi su EF. Se stavi per produrre il tuo servizio per non fare altro che esporre i tuoi dati, allora è una scommessa decente. Utilizza un'interfaccia REST e può esporre i dati in formato ATOM.
- ASP.NET Dynamic Data non è una strategia di accesso ai dati. Vedi http://www.asp.net/dynamicdata/.
Le distinzioni sono abbastanza chiare che una banale quantità di ricerche le avrebbe chiarite.
Distinzioni non molto chiare per chi non usa prodotti Microsoft ma ha un interesse generale per le tecnologie alla base di questi prodotti. Esistiamo e possiamo prendere in considerazione domande interessanti come questa. Non per niente – IlDan
Mi riferivo alla domanda originale. Forse lo avresti formulato diversamente. –
Hanno una strategia di dati da anni. Infatti puoi e dovresti cercare "Microsoft Data Access Strategy" e troverai link vecchi e nuovi (vale a dire l'anno 1998 e la loro strategia OLEDB).
Penso che quello che stai cercando sia here dell'anno 2007 che, anche se ha 2 anni, riguarda XML, ADO.NET, dati, LINQ, SQL Server, Visual Studio Orche, Entity Framework ... domanda Microsoft ha una strategia di accesso ai dati?:
Sì, si scopre che lo facciamo. Microsoft prevede una piattaforma di dati di entità che consente ai clienti di definire un modello di dati di entità comune tra servizi di dati e applicazioni. La Piattaforma Entità Dati è una visione multi-release, con versioni future di strumenti di reporting , replica, definizione dei dati, sicurezza , ecc. Tutti costruiti intorno a un modello di dati di entità comune. ...
Mike Pizzo, Architetto, dati programmabilità
spero che aiuta.
Trovo l'articolo http://msdn.microsoft.com/en-us/magazine/cc700331.aspx una bella introduzione tecnica a Entity Framework se non si ha familiarità con i concetti sottostanti.
Qui è una sezione che è rilevante a questa domanda spiegare alcuni degli obiettivi e rapporto con ADO.Net di EF ...
ADO.NET Entity Framework è un'evoluzione di ADO.NET e la prima implementazione concreta dell'EDM, fornendo un livello più alto di astrazione quando si sviluppa su un database relazionale. Nella versione 1.0, il team si è concentrato sulla creazione di una piattaforma, più che un semplice ORM, che consentirà agli sviluppatori di lavorare contro un modello concettuale o oggettuale con una mappatura molto flessibile e la capacità di adattarsi a un livello elevato di divergenza dal magazzino sottostante.
Questo elevato grado di flessibilità e divergenza dal negozio sottostante è la chiave per consentire l'evoluzione separata del database e delle applicazioni. Quando viene apportata una modifica nello schema del database, l'applicazione viene isolata dalla modifica da Entity Framework e spesso non è necessario riscrivere le parti dell'applicazione, ma piuttosto semplicemente aggiornare i file di mapping, se necessario, per adattarsi alla modifica.
Per iniziare l'evoluzione della piattaforma ADO.NET, Entity Framework è costruito sopra il modello di provider ADO.NET 2.0 esistente, con i provider esistenti aggiornati leggermente per supportare il nuovo Entity Framework e la funzionalità ADO.NET 3.5. Abbiamo scelto di implementare il modello di provider ADO.NET esistente per garantire un modello di provider familiare alla comunità di sviluppo.
Si dovrebbe fare una domanda wiki della comunità poiché non c'è una risposta definitiva –
suona bene, grazie! –
In realtà, sarebbe meglio chiudere come un duplicato di http://stackoverflow.com/questions/669242/ado-net-data-services-theirplace-in-overall-design e molti altri. –