Почему история MS Data Access так раздроблена? Это природа доступа к данным или просто MS?

Этот вопрос StackOverflow спрашивает, «где я могу получить Microsoft.Data.Objects»

Получается, что ответ был, вероятно, в CTP4 (сначала код) версии Entity Framework 4 Однако там было много догадок. Включая

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

10 лет назад, если кто-то задавал подобный вопрос, он мог получить DAO, RDO, ADO.

Это просто природа зверя или это MS.

Этот шаблон происходит с другими поставщиками? Где базовая стратегия доступа к данным либо перенесена, либо изменена?

Это сочетание исторических / эволюционных и рыночных причин

Во время работы в Microsoft несколько лет назад было ясно, что в разработке было несколько различных предложений для данных. Каждое из предложений было нацелено на определенный рынок или вариант использования, например:

1. Доступ был нацелен на пользователей настольных компьютеров, которым удобны системы индексации карт, которые могли создавать приложения, используя формы и отчеты. SQL был естественным дополнением. Все они использовали свой собственный механизм базы данных локальной машины под названием «JET». В конце концов, JET оказался в стороне - на виноградной лозе говорилось, что отсутствие (надежного) контроля источников означало, что они потеряли большую часть источника.

2. FoxPro был нацелен на пользователей настольных компьютеров, которым нужна скорость по сравнению с реляционными данными.

3. SQL Server был «большой» системой баз данных на стороне предприятия / сервера со всеми масштабами / мощностью / доступностью и т. Д., Которые нужны предприятиям. IIRC, MS лицензировали версию Sybase 6 для сборки MSSQL.

Со временем некоторые границы стали размытыми - например, SQL Server теперь может работать на настольном компьютере, но сценарий использования остался.

Таким образом, это дает нам 3 «бэкенда» - базы данных, производимые Microsoft.

В дополнение к этому, для доступа к этим системам были предоставлены разные уровни API разработчика:

1. Изначально API-интерфейсов было немного - вы написали свой код внутри приложения (FoxPro / Access). VBA был одним из методов.

2. Microsoft внедрила MS ODBC для подключения к конкурирующим системам, чтобы Windows могла общаться с большими базами данных, такими как Oracle, Sybase и т. Д. Excel был одним из наиболее заметных приложений для получения инструментов ODBC - извлечения данных из вашей большой БД, манипулирования ими и графиками продуктов. / graphs и т. д. Многие поставщики баз данных в конечном итоге внедрили ODBC для обеспечения возможности подключения разнородных клиентов, поэтому эта стратегия была успешной ... в некоторой степени - ODBC можно рассматривать как представляющую наименьший общий знаменатель.

3. Различные команды начали разрабатывать свои собственные способы доступа к базе данных, такой как DAO (объекты доступа к данным) для локальных и RDO (удаленные объекты данных) для удаленных, доступных через VB, который был самым популярным продуктом для разработчиков MS в то время.

4. Внутренние усилия по рационализации этих разнообразных API и предоставлению единого / унифицированного и очень гибкого API доступа к базе данных дали нам OLEDB, но в него было очень трудно попасть (много шаблонов C ++).

5. OLEDB нельзя было использовать из VB, поэтому ADO разрабатывался с использованием методов ActiveX, поэтому его можно было повторно использовать всем, что может делать COM / OLE / ActiveX, то есть Access, Excel, VB и, следовательно, ASP стали базой данных.

6. Когда мы перешли в эру .NET, ADO естественным образом переместился в среду .NET, которая принесла различные преимущества.

7. С появлением LINQ реальный механизм доступа к базе данных стал менее проблематичным.

Предостережение - я ушел некоторое время назад, так что моя память немного размыта

Чтобы быть справедливым, все те, что вы упоминаете, построены на ADO.NET. До этого ADO был предпочтительным маршрутом какое-то время, но DAO просто зависал, потому что он был родным для баз данных Microsoft Access. RDO был мертв по прибытии, насколько я могу судить.

Я думаю, что со всеми различными фреймворками проблема заключается в том, что они пытаются дать решение для всех и конкурировать с любой другой платформой. Если вы хотите простой способ использовать SQL в своем коде, перейдите к System.Data. Если вы хотите ORM, используя Entity Framework. Для чего-то промежуточного затем используйте данные Enterprise Library. Каждый хочет чего-то другого.

Есть также проблема, что MS - очень большая компания с разными командами с разными планами. Например, почему у них также есть 3 текстовых процессора (о которых я знаю).

Лично я думаю, что это скорее результат влияния маркетинга в Microsoft. По праву говоря, большинство этих технологий можно было бы просто выпустить в виде обновлений версий более старых версий, но, похоже, существует большая потребность в этом образе постоянного переосмысления даже чего-то базового, такого как уровень доступа к данным.

Это сама природа ИТ! Вещи меняются! В мире Java у них было то же самое ... JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0 и так далее.