Por que a história do MS Data Access está tão fraturada? É a natureza do acesso a dados ou é apenas MS?

Esta pergunta StackOverflow pergunta "onde posso obter Microsoft.Data.Objects"

Acontece que a resposta foi provavelmente a do CTP4 (código primeiro) do Entity Framework 4. No entanto, há muitas suposições. Incluindo

• System.Data
• Estrutura de entidade
• Microsoft.ApplicationBlocks.Data
• Microsoft.Practices.EnterpriseLibrary.Data

Há 10 anos, se alguém fizesse uma pergunta semelhante, poderia ter recebido DAO, RDO, ADO.

É apenas a natureza da besta ou é MS.

Esse padrão acontece com outros fornecedores? Onde a estratégia de acesso a dados base é agrupada ou alterada?

É uma combinação de razões históricas / evolucionárias e de força de mercado

Enquanto trabalhava na Microsoft há alguns anos, ficou claro que havia várias ofertas de dados diferentes em desenvolvimento. Cada uma das ofertas visava um mercado ou caso de uso específico, por exemplo:

1. O acesso era destinado a usuários de desktop confortáveis ​​com sistemas de indexação de cartões que podiam criar aplicativos usando os formulários e relatórios. SQL foi uma adição natural. Tudo isso usou seu 'mecanismo de banco de dados da máquina local chamado' JET '. Eventualmente, o JET ficou de fora - a palavra na videira era que a falta de controle (confiável) da fonte significava que eles haviam perdido uma grande parte da fonte.

2. O FoxPro era voltado para usuários de desktop que desejavam velocidade sobre dados relacionais.

3. O SQL Server era o 'grande' sistema de banco de dados da Empresa / Servidor, com toda a escala / potência / disponibilidade, etc, que as empresas precisam. IIRC, MS licenciou uma versão do Sybase 6 na qual construir o MSSQL.

Com o tempo, alguns dos limites ficaram embaçados - por exemplo, o SQL Server pode ser executado em uma máquina desktop agora, mas o caso de uso permaneceu.

Portanto, isso nos dá três 'back-ends' - produtos de banco de dados produzidos pela Microsoft.

Para adicionar à mistura, havia diferentes níveis de API do desenvolvedor fornecidos para obter acesso a esses sistemas:

1. Inicialmente, não havia muito no caminho das APIs - você escreveu seu código dentro do aplicativo (FoxPro / Access). O VBA foi um método.

2. A Microsoft implementou o MS ODBC para conectar-se a sistemas concorrentes para que o Windows pudesse conversar com grandes bancos de dados como Oracle, Sybase etc. O Excel foi um dos aplicativos mais notáveis ​​para obter ferramentas ODBC - extraia dados de seu grande banco de dados, manipule-o e gráficos de produtos / gráficos, etc. Muitos fornecedores de banco de dados acabaram implementando ODBC para permitir a conexão de clientes diferentes, de modo que essa estratégia foi bem-sucedida .. até certo ponto - o ODBC poderia ser considerado como o menor denominador comum.

3. Diferentes equipes começaram a produzir suas próprias maneiras de acessar um mecanismo de banco de dados como o DAO (Data Access Objects) para local e o RDO (Remote Data Objects) para remoto, acessível através do VB, que era o produto de desenvolvedor de MS mais popular da época.

4. Um esforço interno para racionalizar essas diversas APIs e fornecer uma API única / unificada de acesso ao banco de dados altamente flexível nos deu OLEDB, mas era muito difícil entrar (muitos modelos de C ++).

5. O OLEDB não pôde ser usado no VB; portanto, o ADO foi desenvolvido usando técnicas ActiveX, tornando-se reutilizável por qualquer coisa que pudesse fazer COM / OLE / ActiveX, ou seja, Access, Excel, VB e, portanto, ASP tornou-se ativado por banco de dados.

6. À medida que passamos para a era .NET, o ADO foi naturalmente movido para um ambiente .NET que trouxe vários benefícios.

7. Com o advento do LINQ, o mecanismo real de acesso ao banco de dados se tornou menos problemático.

Advertência - eu parti há algum tempo, agora, então minha memória está um pouco confusa

Para ser justo, todos os que você mencionou foram criados sobre o ADO.NET. Antes disso, o ADO era a rota preferida por um tempo, mas o DAO meio que ficava por aí porque era nativo dos bancos de dados do Microsoft Access. RDO estava morto na chegada, pelo que posso dizer.

Com todas as diferentes estruturas mencionadas, acho que o problema é que elas estão tentando dar uma solução para todos e competir com todas as outras plataformas. Se você deseja uma maneira simples de usar SQL no seu código, vá para System.Data. Se você deseja um ORM usando o Entity Framework. Para algo intermediário, use Dados da Biblioteca Corporativa. Todo mundo quer algo diferente.

Há também a questão de que a MS é uma empresa muito grande, com equipes diferentes e agendas diferentes. Por exemplo, por que eles também têm três processadores de texto (que eu conheço).

Pessoalmente, acho que é mais um resultado da influência do marketing na Microsoft. Por todos os direitos, a maioria dessas tecnologias poderia ser facilmente lançada como atualização de versões anteriores, mas parece haver uma grande necessidade de colocar essa imagem de reinventar continuamente até algo tão básico quanto uma camada de acesso a dados.

Essa é a própria natureza da TI! As coisas mudam! No mundo Java, eles tinham a mesma coisa ... JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0 e assim por diante.