Pourquoi l'histoire de MS Data Access est-elle si fracturée? Est-ce la nature de l'accès aux données ou est-ce simplement MS?

Cette question StackOverflow demande "où puis-je obtenir Microsoft.Data.Objects"

Il s'avère que la réponse était probablement que c'est dans la version CTP4 (code en premier) d'Entity Framework 4 Cependant, il y avait beaucoup de suppositions. Comprenant

• System.Data
• Cadre d'entité
• Microsoft.ApplicationBlocks.Data
• Microsoft.Practices.EnterpriseLibrary.Data

Il y a 10 ans, si quelqu'un posait une question similaire, il aurait pu obtenir DAO, RDO, ADO.

Est-ce simplement la nature de la bête ou est-ce la SEP?

Ce modèle se produit-il avec d'autres fournisseurs? Où la stratégie d'accès aux données de base est-elle enveloppée ou modifiée?

C'est une combinaison de raisons historiques / évolutives et de forces du marché

En travaillant chez Microsoft il y a quelques années, il était clair que plusieurs offres de données différentes étaient en cours de développement. Chacune des offres visait un marché ou un cas d'utilisation particulier, par exemple:

1. L'accès était destiné aux utilisateurs de bureau à l'aise avec les systèmes d'indexation des cartes qui pouvaient créer des applications à l'aide des formulaires et des rapports. SQL était un ajout naturel. Tout cela utilisait son «propre moteur de base de données de machine locale nommé« JET ». Finalement, JET a été mis à l'écart - le mot sur la vigne était que le manque de contrôle de source (fiable) signifiait qu'ils avaient perdu une grande partie de la source.

2. FoxPro était destiné aux utilisateurs de postes de travail qui souhaitaient accélérer les données relationnelles.

3. SQL Server était le «grand» système de base de données côté entreprise / serveur avec toute l'échelle / puissance / disponibilité, etc. dont les entreprises ont besoin. IIRC, MS a autorisé une version de Sybase 6 sur laquelle construire MSSQL.

Au fil du temps, certaines limites sont devenues floues - par exemple, SQL Server peut maintenant fonctionner sur une machine de bureau, mais le cas d'utilisation est resté.

Cela nous donne donc 3 `` backends '' - produits de base de données produits par Microsoft.

Pour ajouter au mélange, il y avait alors différents niveaux d'API de développeur fournis pour accéder à ces systèmes:

1. Au départ, il n'y avait pas grand-chose en termes d'API - vous avez écrit votre code dans l'application (FoxPro / Access). VBA était une méthode.

2. Microsoft a implémenté MS ODBC afin de se connecter à des systèmes concurrents afin que Windows puisse communiquer avec de grandes bases de données comme Oracle, Sybase, etc. Excel a été l'une des applications les plus remarquables pour obtenir des outils ODBC - extraire des données de votre grande base de données, les manipuler et les tableaux de produits / graphs, etc. De nombreux fournisseurs de bases de données ont fini par implémenter ODBC pour permettre aux clients disparates de se connecter, donc cette stratégie a réussi. dans une certaine mesure - ODBC peut être considéré comme représentant le plus petit dénominateur commun.

3. Différentes équipes ont commencé à produire leurs propres moyens d'accéder à un moteur de base de données comme DAO (Data Access Objects) pour local et RDO (Remote Data Objects) pour distant, accessible via VB, qui était le produit de développement MS le plus populaire à l'époque.

4. Un effort interne pour rationaliser ces diverses API et fournir une API d'accès à la base de données hautement flexible unique / unifiée nous a donné OLEDB, mais il était très difficile d'y accéder (beaucoup de modèles C ++).

5. OLEDB ne pouvait pas être utilisé à partir de VB, donc ADO a été développé à l'aide de techniques ActiveX, il est donc devenu réutilisable par tout ce qui pouvait faire COM / OLE / ActiveX, ce qui signifie qu'Access, Excel, VB et donc ASP sont devenus compatibles avec la base de données.

6. Alors que nous entrions dans l'ère .NET, ADO s'est naturellement déplacé dans un environnement .NET qui a apporté divers avantages.

7. Avec l'avènement de LINQ, le véritable mécanisme d'accès à la base de données est devenu moins problématique.

Mise en garde - Je suis parti il ​​y a quelque temps maintenant, donc ma mémoire est un peu floue

Pour être juste, tous ceux que vous mentionnez sont construits sur ADO.NET. Avant cela, ADO était la route préférée pendant un certain temps, mais DAO restait en quelque sorte parce qu'il était natif pour les bases de données Microsoft Access. RDO était mort à l'arrivée de ce que je peux dire.

Avec tous les différents cadres que vous mentionnez, je pense que le problème est qu'ils essaient de donner une solution pour tout le monde et de rivaliser avec toutes les autres plates-formes. Si vous voulez un moyen simple d'utiliser simplement SQL dans votre code, optez pour System.Data. Si vous voulez un ORM utilisant Entity Framework. Pour quelque chose entre les deux, utilisez les données de la bibliothèque d'entreprise. Tout le monde veut quelque chose de différent.

Il y a aussi le problème que MS est une très grande entreprise avec des équipes différentes avec des programmes différents. Par exemple, pourquoi ont-ils également 3 traitements de texte (que je sache).

Personnellement, je pense que c'est plus le résultat de l'influence du marketing au sein de Microsoft. Par tous les droits, la plupart de ces technologies pourraient facilement être publiées sous la forme de mises à niveau de versions des anciennes versions, mais il semble qu'il y ait un grand besoin de mettre sur cette image de réinventer continuellement même quelque chose d'aussi basique qu'une couche d'accès aux données.

C'est la nature même de l'informatique! Les choses changent! Dans le monde Java, ils avaient la même chose ... JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0 et ainsi de suite.