왜 MS 데이터 액세스 스토리가 그렇게 골절 되었습니까? 데이터 액세스의 특성입니까, 아니면 MS입니까?

이 StackOverflow 질문 은 "Microsoft.Data.Objects를 어디서 얻을 수 있습니까?"

대답은 아마도 Entity Framework 4의 CTP4 (코드 우선) 릴리스에 있었을 것입니다. 그러나 많은 추측이 있습니다. 포함

• System.Data
• 엔터티 프레임 워크
• Microsoft.ApplicationBlocks.Data
• Microsoft.Practices.EnterpriseLibrary.Data

10 년 전에 누군가 비슷한 질문을하면 DAO, RDO, ADO를 받았을 수 있습니다.

이것이 야수의 본성 일까 아니면 MS인가?

이 패턴은 다른 공급 업체에서도 발생합니까? 기본 데이터 액세스 전략은 어디에 랩핑되거나 변경됩니까?

그것은 역사 / 진화론과 시장의 힘의 이유의 조합입니다

몇 년 전에 Microsoft에서 근무하는 동안 개발에 여러 가지 데이터가 제공되었다는 것이 분명했습니다. 각 오퍼링은 다음과 같은 특정 시장 또는 사용 사례를 목표로합니다.

1. 액세스는 양식 및 보고서를 사용하여 응용 프로그램을 구축 할 수있는 카드 색인 시스템에 익숙한 데스크톱 사용자를 대상으로했습니다. SQL은 자연스럽게 추가되었습니다. 이것은 모두 'JET'이라는 자체 로컬 컴퓨터 데이터베이스 엔진을 사용했습니다. 결국 JET는 부적절했습니다. 포도 덩굴에 관한 단어는 (신뢰할 수있는) 소스 컨트롤이 없다는 것이 소스 의 큰 덩어리를 잃어 버렸다는 것을 의미했습니다 .

2. FoxPro는 관계형 데이터보다 빠른 속도를 원하는 데스크톱 사용자를 대상으로합니다.

3. SQL Server는 엔터프라이즈에 필요한 모든 규모 / 전력 / 가용성 등을 갖춘 엔터프라이즈 / 서버 측 '큰'데이터베이스 시스템입니다. IIRC, MS는 MSSQL을 빌드 할 Sybase 6 버전을 라이센스했습니다.

시간이 지남에 따라 일부 경계가 흐려졌습니다. 예를 들어 SQL Server는 이제 데스크톱 컴퓨터에서 실행할 수 있지만 사용 사례는 그대로 남아 있습니다.

따라서 이것은 Microsoft에 의해 생성 된 데이터베이스 제품인 3 개의 '백엔드'를 제공합니다.

믹스에 추가하기 위해 다음과 같은 시스템에 액세스하기 위해 다양한 레벨의 개발자 API가 제공되었습니다.

1. 처음에는 API 방식이별로 없었습니다. 응용 프로그램 내부에 코드를 작성했습니다 (FoxPro / Access). VBA는 한 가지 방법이었습니다.

2. Microsoft는 경쟁 시스템에 연결하기 위해 MS ODBC를 구현하여 Windows가 Oracle, Sybase 등과 같은 큰 데이터베이스와 통신 할 수 있도록했습니다. Excel은 ODBC 도구를 얻는 데 유용한 앱 중 하나였습니다. 큰 DB에서 데이터를 가져 와서 조작하고 제품 차트 / graphs 등 많은 데이터베이스 벤더들이 이종 클라이언트가 연결할 수 있도록 ODBC를 구현하게되었으므로이 전략은 어느 정도 성공을 거두었습니다. ODBC는 최저 공통 분모를 나타내는 것으로 간주 될 수 있습니다.

3. 다른 팀은 당시 가장 인기있는 MS 개발자 제품인 VB를 통해 액세스 할 수있는 로컬 용 DAO (데이터 액세스 개체) 및 원격 용 RDO (원격 데이터 개체)와 같은 데이터베이스 엔진에 액세스하는 고유 한 방법을 만들기 시작했습니다.

4. 이러한 다양한 API를 합리화하고 단일 / 통일 된 매우 유연한 데이터베이스 액세스 API를 제공하려는 내부 노력으로 인해 OLEDB가 제공되었지만 많은 C ++ 템플릿을 사용하기가 매우 어려웠습니다.

5. VB에서는 OLEDB를 사용할 수 없었으므로 ADO는 ActiveX 기술을 사용하여 개발되었으므로 Access, Excel, VB를 의미하는 COM / OLE / ActiveX를 수행 할 수있는 모든 것에 의해 재사용이 가능해졌으며 ASP는 데이터베이스를 사용할 수있게되었습니다.

6. .NET 시대로 옮겨 감에 따라 ADO는 자연스럽게 .NET 환경으로 옮겨져 다양한 이점을 얻었습니다.

7. LINQ의 등장으로 실제 데이터베이스 액세스 메커니즘은 문제가되지 않았습니다.

주의 사항-얼마 전에 떠났으므로 기억이 조금 흐릿합니다.

공정하게 말하면 언급 한 모든 내용은 ADO.NET을 기반으로합니다. 그 전에는 ADO가 한동안 선호되는 경로 였지만 DAO는 Microsoft Access Database의 기본 기능이기 때문에 일종의 걸림돌이었습니다. 내가 알 수있는 것에서 RDO가 도착하자 죽었다

당신이 언급 한 모든 다른 프레임 워크와 함께, 문제는 그들이 모든 사람을위한 솔루션을 제공하고 다른 모든 플랫폼과 경쟁하려고한다는 것입니다. 코드에서 SQL을 사용하는 간단한 방법을 원하면 System.Data로 이동하십시오. Entity Framework를 사용하여 ORM을 원하는 경우 그 사이에 무언가를 위해 Enterprise Library Data를 사용하십시오. 누구나 다른 것을 원합니다.

MS가 다른 의제를 가진 다른 팀을 가진 매우 큰 회사라는 문제도 있습니다. 예를 들어 왜 3 워드 프로세서 (내가 아는)가 있습니까?

개인적으로 저는 이것이 마이크로 소프트 내 마케팅의 영향으로 인한 것이라고 생각합니다. 모든 권리에 의해, 이들 기술의 대부분은 이전 버전의 버전 업그레이드로 쉽게 출시 될 수 있지만, 데이터 액세스 계층과 같은 기본적인 것까지 지속적으로 재창조해야한다는이 이미지를 추가 할 필요가있는 것 같습니다.

이것이 바로 IT의 본질입니다! 모든것은 변한다! Java 세계에서는 JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0 등 동일한 기능을 수행했습니다.