Чому історія 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.

Це просто природа звіра чи це РС.

Чи трапляється ця модель з іншими постачальниками? Де стратегія доступу до базових даних згортається або змінюється?

Це поєднання історичних / еволюційних та ринкових причин

Працюючи в Microsoft кілька років тому, було зрозуміло, що існує декілька різних пропозицій даних у розробці. Кожна з пропозицій була спрямована на конкретний ринок або випадок використання, наприклад:

1. Доступ був орієнтований на користувачів настільних комп’ютерів, зручних у системах індексації карт, які могли збирати програми за допомогою форм та звітів. SQL було природним доповненням. Це все використовувало власний механізм бази даних локальних машин під назвою "JET". Врешті-решт JET перейшов у бік - слово про виноградну лозу полягало в тому, що відсутність (надійного) контролю над джерелами означала, що вони втратили великий шматок джерела.

2. FoxPro був орієнтований на користувачів настільних ПК, які бажали швидкості порівняння реляційних даних.

3. SQL Server був «великою» системою баз даних на базі Enterprise / 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 - витягуйте дані з великої БД, маніпулюйте ними та діаграмами продуктів / графіки тощо. Багато постачальників баз даних закінчилися впроваджувати 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, власне механізм доступу до бази даних став менш проблематичним.

Caveat - я покинув деякий час тому, тому моя пам’ять трохи нечітка

Для справедливості всі згадані вами побудовані на версії ADO.NET. До цього ADO деякий час був улюбленим маршрутом, але DAO просто зависав, бо він був рідним для баз даних Microsoft Access. RDO був мертвий після прибуття з того, що я можу сказати.

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

Існує також питання про те, що MS - дуже велика компанія з різними командами з різними програмами. Наприклад, чому вони також мають 3 текстові процесори (що я знаю).

Особисто я вважаю, що це скоріше результат впливу маркетингу в Microsoft. За всіма правами, більшість цих технологій легко можна було б просто випустити як оновлення версій старих версій, але, мабуть, існує велика потреба в цьому образі постійно відновлювати навіть щось таке базове, як рівень доступу до даних.

Це сама природа ІТ! Речі ЗМІН! У світі Java у них було те саме: JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0 тощо.