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

11

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

Risulta che la risposta era probabilmente quella relativa alla versione CTP4 (in primo luogo in codice) di Entity Framework 4 Comunque là dove un sacco di ipotesi. Compreso

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

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

Questa è solo la natura della bestia o è MS.

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

    
posta Conrad Frix 29.10.2010 - 00:25
fonte

4 risposte

11

È una combinazione di motivi storico / evolutivo e di forza di mercato

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

  1. L'accesso era rivolto agli utenti desktop che si sentivano a proprio agio con i sistemi di indicizzazione delle carte che potevano creare applicazioni utilizzando i moduli e i report. SQL era un'aggiunta naturale. Tutto questo ha usato 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 del codice significava che perdevano un grosso pezzo della fonte.

  2. FoxPro si rivolge agli utenti desktop che desideravano velocità rispetto ai dati relazionali.

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

Nel tempo, alcuni dei contorni sono diventati sfocati - ad es. SQL Server può ora essere eseguito su un computer desktop, ma il caso d'uso è rimasto.

Quindi questo ci dà 3 "back-end" - prodotti di database prodotti da Microsoft.

Per aggiungere al mix, erano disponibili diversi livelli di API per sviluppatori 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 ai sistemi concorrenti in modo che Windows potesse parlare con grandi database come Oracle, Sybase, ecc. Excel era una delle app degne di nota per ottenere strumenti ODBC: estrarre i dati dal tuo grande DB manipolarlo e diagrammi / grafici dei prodotti, ecc. Molti fornitori di database hanno finito per implementare ODBC per consentire ai diversi clienti di connettersi, quindi questa strategia ha avuto successo .. in una certa misura - ODBC potrebbe essere considerato come rappresentante del 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 era il prodotto di sviluppo MS più popolare al momento.

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

  5. Non è stato possibile utilizzare OLEDB da VB, quindi ADO è stato sviluppato utilizzando tecniche ActiveX, quindi è diventato riutilizzabile da qualsiasi cosa possa fare COM / OLE / ActiveX, ovvero Access, Excel, VB e, quindi, ASP diventato Database-enabled.

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

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

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

    
risposta data 18.02.2011 - 11:10
fonte
5

Per essere onesti, tutti quelli che menzioni sono costruiti su ADO.NET. Prima che ADO fosse la route preferita per un po 'di tempo, DAO si bloccava solo perché era nativo per i database Microsoft Access. RDO era morto all'arrivo da quello che posso dire.

Con tutti i diversi quadri che menzioni, penso che il problema sia che stanno cercando di dare una soluzione a tutti e di competere con ogni altra piattaforma. Se si desidera un modo semplice per utilizzare semplicemente SQL nel codice, andare su System.Data. Se si desidera un ORM utilizzando Entity Framework. Per qualcosa in mezzo, quindi utilizzare Enterprise Library Data. Tutti vogliono qualcosa di diverso.

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

    
risposta data 29.10.2010 - 00:52
fonte
2

Personalmente ritengo che sia più un risultato dell'influenza del marketing all'interno di Microsoft. Di tutti i diritti, la maggior parte di queste tecnologie potrebbe essere facilmente rilasciata come aggiornamento delle versioni precedenti, ma sembra esserci un grande bisogno di mettere su questa immagine di reinventare continuamente anche qualcosa di semplice come un livello di accesso ai dati.

    
risposta data 29.10.2010 - 03:00
fonte
0

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

    
risposta data 15.12.2010 - 20:40
fonte

Leggi altre domande sui tag