Dlaczego historia MS Data Access jest tak rozbita? Czy to natura dostępu do danych, czy tylko stwardnienie rozsiane?

To pytanie StackOverflow pyta „skąd mogę pobrać Microsoft.Data.Objects”

Okazuje się, że odpowiedzią było prawdopodobnie to, że jest w wersji CTP4 (najpierw kod) Entity Framework 4 Jednak tam było wiele domysłów. Włącznie z

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

10 lat temu, gdyby ktoś zadał podobne pytanie, mógł dostać DAO, RDO, ADO.

Czy to tylko natura bestii czy to stwardnienie rozsiane.

Czy ten wzór występuje u innych dostawców? Gdzie podstawowa strategia dostępu do danych jest opakowana lub zmieniana?

Jest to połączenie przyczyn historycznych / ewolucyjnych i rynkowych

Podczas pracy w firmie Microsoft kilka lat temu było jasne, że opracowywanych jest kilka różnych ofert danych. Każda z ofert była skierowana na konkretny rynek lub przypadek użycia, np .:

1. Dostęp był skierowany do użytkowników komputerów stacjonarnych, którzy czują się komfortowo z systemami indeksowania kart, którzy mogą budować aplikacje przy użyciu formularzy i raportów. SQL był naturalnym dodatkiem. W tym wszystkim wykorzystano własny silnik bazy danych maszyny lokalnej o nazwie „JET”. W końcu JET został odsunięty na bok - słowo o winorośli winogron brzmiało, że brak (niezawodnej) kontroli źródła oznaczał, że stracili dużą część źródła.

2. FoxPro był przeznaczony dla użytkowników komputerów stacjonarnych, którzy chcieli prędkości w porównaniu z danymi relacyjnymi.

3. SQL Server był „dużym” systemem bazy danych Enterprise / Server ze wszystkimi skalami / mocą / dostępnością itp., Których potrzebują przedsiębiorstwa. IIRC, MS licencjonowało wersję Sybase 6, na której można budować MSSQL.

Z czasem niektóre granice zostały zatarte - np. SQL Server może teraz działać na komputerze stacjonarnym, ale przypadek użycia pozostał.

To daje nam 3 „zaplecza” - produkty bazodanowe produkowane przez Microsoft.

Aby dodać do miksu, udostępniono różne poziomy interfejsu API dla programistów w celu uzyskania dostępu do tych systemów:

1. Początkowo interfejsów API nie było wiele - kod został napisany w aplikacji (FoxPro / Access). VBA była jedną z metod.

2. Microsoft wdrożył MS ODBC w celu łączenia się z konkurencyjnymi systemami, aby Windows mógł komunikować się z dużymi bazami danych, takimi jak Oracle, Sybase itp. Excel był jedną z godnych uwagi aplikacji do uzyskiwania narzędzi ODBC - pobieranie danych z dużego DB, manipulowanie nim i kartami produktów / wykresy itp. Wielu dostawców baz danych ostatecznie wdrożyło ODBC, aby umożliwić odmiennym klientom łączenie się, więc ta strategia się powiodła .. do pewnego stopnia - ODBC można uznać za reprezentujący najniższy wspólny mianownik.

3. Różne zespoły zaczęły opracowywać własne sposoby dostępu do silnika bazy danych, takiego jak DAO (Data Access Objects) dla lokalnego i RDO (Remote Data Objects) dla zdalnego, dostępnego przez VB, który był wówczas najpopularniejszym produktem deweloperskim MS.

4. Wewnętrzny wysiłek zracjonalizowania tych różnorodnych interfejsów API i zapewnienia pojedynczego / zunifikowanego wysoce elastycznego interfejsu API dostępu do bazy danych dał nam OLEDB, ale bardzo trudno było się do niego dostać (wiele szablonów C ++).

5. OLEDB nie mógł być używany z VB, więc ADO został opracowany przy użyciu technik ActiveX, więc stał się ponownie użyteczny przez wszystko, co potrafiłoby wykonać COM / OLE / ActiveX, co oznacza, że ​​Access, Excel, VB, a zatem ASP został włączony do bazy danych.

6. Gdy wkroczyliśmy w erę .NET, ADO zostało naturalnie przeniesione do środowiska .NET, które przyniosło różne korzyści.

7. Wraz z pojawieniem się LINQ faktyczny mechanizm dostępu do bazy danych stał się mniejszym problemem.

Zastrzeżenie - wyszedłem jakiś czas temu, więc moja pamięć jest trochę rozmyta

Szczerze mówiąc, wszystkie te, o których wspominasz, są zbudowane na ADO.NET. Wcześniej ADO była ulubioną trasą przez jakiś czas, ale DAO po prostu się trzymała, ponieważ była natywna dla baz danych Microsoft Access. RDO był martwy w dniu przyjazdu z tego, co mogę powiedzieć.

Biorąc pod uwagę wszystkie różne frameworki, o których wspominasz, myślę, że problem polega na tym, że próbują dać rozwiązanie wszystkim i konkurować z każdą inną platformą. Jeśli chcesz w prosty sposób po prostu użyć SQL w kodzie, wybierz System.Data. Jeśli chcesz ORM za pomocą Entity Framework. Aby znaleźć coś pomiędzy, skorzystaj z danych Enterprise Library Data. Każdy chce czegoś innego.

Istnieje również problem, że MS jest bardzo dużą firmą z różnymi zespołami i różnymi programami. Na przykład, dlaczego mają również 3 edytory tekstu (o których wiem).

Osobiście uważam, że jest to bardziej efekt marketingu w Microsoft. Zgodnie z wszelkimi prawami, większość tych technologii może być łatwo wydana jako aktualizacje starszych wersji, ale wydaje się, że istnieje duża potrzeba wprowadzenia tego obrazu ciągłego przekształcania nawet czegoś tak podstawowego, jak warstwa dostępu do danych.

Taka jest natura IT! Rzeczy ZMIANA! W świecie Java mieli to samo ... JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0 i tak dalej.