Perché la storia di MS Data Access è così fratturata? È la natura dell'accesso ai dati o è solo SM?

Questa domanda StackOverflow chiede "dove posso trovare Microsoft.Data.Objects"

Si scopre che la risposta era probabilmente che si trova nella versione CTP4 (prima di codice) di Entity Framework 4 Tuttavia lì dove molte ipotesi. Compreso

• System.Data
• Entity Framework
• Microsoft.ApplicationBlocks.Data
• Microsoft.Practices.EnterpriseLibrary.Data

10 anni fa, se qualcuno avesse posto una domanda simile, avrebbe potuto ottenere DAO, RDO, ADO.

È solo la natura della bestia o è la SM?

Questo schema si verifica con altri fornitori? Dove viene spostata o modificata la strategia di accesso ai dati di base?

È una combinazione di ragioni storiche / evolutive e di forza di mercato

Lavorando in Microsoft alcuni anni fa, era chiaro che c'erano diverse offerte di dati in fase di sviluppo. Ciascuna offerta era rivolta a un particolare mercato o caso d'uso, ad esempio:

1. L'accesso era rivolto agli utenti desktop a proprio agio con i sistemi di indicizzazione delle carte in grado di creare applicazioni utilizzando moduli e report. SQL è stata un'aggiunta naturale. Tutto ciò utilizzava il proprio 'motore di database della macchina locale chiamato' JET '. Alla fine il JET fu messo da parte - la parola sulla vite era che la mancanza di (affidabile) controllo della fonte significava che avevano perso una grossa fetta della fonte.

2. FoxPro era rivolto agli utenti desktop che desideravano velocità rispetto ai dati relazionali.

3. SQL Server era il sistema di database "grande" lato Enterprise / Server con tutta la scala / potenza / disponibilità, ecc. Di cui le aziende hanno bisogno. IIRC, MS ha concesso in licenza una versione di Sybase 6 su cui costruire MSSQL.

Nel corso del tempo, alcuni dei confini si sono offuscati, ad esempio SQL Server può essere eseguito su una macchina desktop ora, ma il caso d'uso è rimasto.

Questo ci dà 3 "back-end": prodotti di database prodotti da Microsoft.

Per aggiungere al mix, c'erano poi diversi livelli di API per sviluppatori forniti per ottenere l'accesso a questi sistemi:

1. Inizialmente, non c'era molto in termini di API: hai scritto il tuo codice all'interno dell'applicazione (FoxPro / Access). VBA era un metodo.

2. Microsoft ha implementato MS ODBC per connettersi a sistemi concorrenti in modo che Windows potesse comunicare con grandi database come Oracle, Sybase, ecc. Excel era una delle app importanti per ottenere strumenti ODBC: estrarre i dati dal tuo grande DB, manipolarli e grafici dei prodotti / grafici, ecc. Molti fornitori di database hanno finito per implementare ODBC per consentire a diversi client di connettersi, quindi questa strategia ha avuto successo ... in una certa misura - ODBC potrebbe essere considerato come il minimo comune denominatore.

3. Diversi team hanno iniziato a produrre i propri modi per accedere a un motore di database come DAO (Data Access Objects) per locale e RDO (Remote Data Objects) per remoto, accessibile tramite VB, che all'epoca era il prodotto per sviluppatori MS più popolare.

4. Uno sforzo interno per razionalizzare queste diverse API e fornire un'API di accesso al database unico / unificato altamente flessibile ci ha dato OLEDB, ma è stato molto difficile entrare in (molti modelli C ++).

5. OLEDB non può essere utilizzato da VB, quindi ADO è stato sviluppato utilizzando le tecniche ActiveX, quindi è diventato riutilizzabile da qualsiasi cosa che potesse fare COM / OLE / ActiveX, il che significa che Access, Excel, VB e quindi ASP sono diventati abilitati al database.

6. Quando ci siamo trasferiti nell'era .NET, ADO è stato naturalmente spostato in un ambiente .NET che ha portato vari vantaggi.

7. Con l'avvento di LINQ, l'attuale meccanismo di accesso al database è diventato meno problematico.

Avvertenza - Sono partito qualche tempo fa, quindi la mia memoria è un po 'confusa

Ad essere onesti, tutti quelli che menzioni sono basati su ADO.NET. Prima di allora, ADO era la via preferita per un po ', ma DAO ha semplicemente sospeso perché era nativo per i database di Microsoft Access. RDO era morto all'arrivo da quello che posso dire.

Con tutti i diversi framework citati, penso che il problema sia che stanno cercando di dare una soluzione a tutti e di competere con ogni altra piattaforma. Se vuoi un modo semplice per usare solo SQL nel tuo codice, scegli System.Data. Se si desidera un ORM utilizzando Entity Framework. Per qualcosa nel mezzo, utilizzare Enterprise Library Data. Tutti vogliono qualcosa di diverso.

C'è anche il problema che MS è un'azienda molto grande con team diversi con programmi diversi. Ad esempio, perché hanno anche 3 word processor (di cui sono a conoscenza).

Personalmente penso che sia più il risultato dell'influenza del marketing all'interno di Microsoft. A tutti i costi, la maggior parte di queste tecnologie potrebbe essere facilmente rilasciata come aggiornamento di versione delle versioni precedenti, ma sembra che ci sia una grande necessità di mettere su questa immagine di reinventare continuamente anche qualcosa di semplice come un livello di accesso ai dati.

Questa è la vera natura dell'IT! Le cose cambiano! Nel mondo Java, avevano la stessa cosa ... JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0 e così via.