¿Por qué la historia de MS Data Access está tan fracturada? ¿Es la naturaleza del acceso a datos o es solo MS?

Esta pregunta de StackOverflow pregunta "¿dónde puedo obtener Microsoft.Data.Objects"?

Resulta que la respuesta fue probablemente que está en la versión CTP4 (código primero) de Entity Framework 4. Sin embargo, hubo muchas conjeturas. Incluso

• Datos de sistema
• Marco de la entidad
• Microsoft.ApplicationBlocks.Data
• Microsoft.Practices.EnterpriseLibrary.Data

Hace 10 años, si alguien hizo una pregunta similar, podría haber obtenido DAO, RDO, ADO.

¿Es esta la naturaleza de la bestia o es MS?

¿Este patrón ocurre con otros proveedores? ¿Dónde se ajusta o cambia la estrategia de acceso a datos base?

Es una combinación de razones históricas / evolutivas y de fuerza de mercado

Mientras trabajaba en Microsoft hace algunos años, estaba claro que había varias ofertas de datos diferentes en desarrollo. Cada una de las ofertas estaba dirigida a un mercado o caso de uso en particular, por ejemplo:

1. El acceso estaba dirigido a usuarios de escritorio que se sienten cómodos con los sistemas de indexación de tarjetas que pueden crear aplicaciones utilizando los formularios e informes. SQL fue una adición natural. Todo esto usó su propio motor de base de datos de máquina local llamado 'JET'. Eventualmente, JET fue dejado de lado: la palabra en la vid era que la falta de control de fuente (confiable) significaba que habían perdido una gran parte de la fuente.

2. FoxPro estaba dirigido a usuarios de escritorio que querían velocidad sobre datos relacionales.

3. SQL Server era el sistema de base de datos 'grande' Enterprise / Server-side con toda la escala / potencia / disponibilidad, etc. que las empresas necesitan. IIRC, MS licencia una versión de Sybase 6 sobre la cual construir MSSQL.

Con el tiempo, algunos de los límites se han vuelto borrosos, por ejemplo, SQL Server puede ejecutarse en una máquina de escritorio ahora, pero el caso de uso se mantuvo.

Esto nos da 3 'back-end': productos de bases de datos producidos por Microsoft.

Para agregar a la mezcla, había diferentes niveles de API de desarrollador para obtener acceso a estos sistemas:

1. Inicialmente, no había mucho en el camino de las API: escribió su código dentro de la aplicación (FoxPro / Access). VBA fue un método.

2. Microsoft implementó MS ODBC para conectarse a sistemas competitivos para que Windows pueda comunicarse con grandes bases de datos como Oracle, Sybase, etc. Excel fue una de las aplicaciones notables para obtener herramientas ODBC: extraer datos de su gran base de datos, manipularla y gráficos de productos / gráficos, etc. Muchos proveedores de bases de datos terminaron implementando ODBC para permitir que clientes dispares se conectaran, por lo que esta estrategia fue exitosa ... hasta cierto punto, ODBC podría considerarse como la representación del mínimo común denominador.

3. Diferentes equipos comenzaron a producir sus propias formas de acceder a un motor de base de datos como DAO (Data Access Objects) para local y RDO (Remote Data Objects) para remoto, accesible a través de VB, que era el producto desarrollador de MS más popular en ese momento.

4. Un esfuerzo interno para racionalizar estas API diversas y proporcionar una API de acceso a la base de datos única / altamente flexible nos dio OLEDB, pero fue muy muy difícil entrar (muchas plantillas de C ++).

5. OLEDB no se pudo usar desde VB, por lo que ADO se desarrolló utilizando técnicas ActiveX, por lo que se volvió reutilizable por cualquier cosa que pudiera hacer COM / OLE / ActiveX, lo que significa que Access, Excel, VB y, por lo tanto, ASP se habilitaron para la base de datos.

6. A medida que avanzamos hacia la era .NET, ADO se trasladó naturalmente a un entorno .NET que trajo varios beneficios.

7. Con la llegada de LINQ, el mecanismo real de acceso a la base de datos se convirtió en un problema menor.

Advertencia: me fui hace un tiempo, así que mi memoria está un poco borrosa

Para ser justos, todos los que menciona están construidos sobre ADO.NET. Antes de eso, ADO era la ruta preferida por un tiempo, pero DAO simplemente se quedaba porque era nativo de las bases de datos de Microsoft Access. RDO estaba muerto a la llegada por lo que puedo decir.

Con todos los diferentes marcos que mencionas, creo que el problema es que están tratando de dar una solución para todos y competir con todas las demás plataformas. Si desea una forma simple de usar SQL en su código, vaya a System.Data. Si desea un ORM utilizando Entity Framework. Para algo intermedio, utilice los datos de la biblioteca empresarial. Todos quieren algo diferente.

También está el problema de que MS es una compañía muy grande con diferentes equipos con diferentes agendas. Por ejemplo, ¿por qué también tienen 3 procesadores de texto (que yo sepa).

Personalmente, creo que es más el resultado de la influencia del marketing dentro de Microsoft. Por todos los derechos, la mayoría de estas tecnologías podrían lanzarse fácilmente como actualizaciones de versión de las versiones anteriores, pero parece ser una gran necesidad poner esta imagen de reinventar continuamente incluso algo tan básico como una capa de acceso a datos.

¡Esta es la naturaleza misma de TI! ¡Las cosas cambian! En el mundo de Java, tenían lo mismo ... JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0, etc.