なぜMS Data Accessのストーリーがそんなに壊れているのですか?データアクセスの性質ですか、それともMSですか?


11

このStackOverflowの質問では、「Microsoft.Data.Objectsはどこで入手できますか」と尋ねられます。

答えは、おそらくEntity Framework 4のCTP4(コードファースト)リリースであることが判明しましたが、そこには多くの推測があります。含む

  • System.Data
  • エンティティフレームワーク
  • Microsoft.ApplicationBlocks.Data
  • Microsoft.Practices.EnterpriseLibrary.Data

10年前に誰かがDAO、RDO、ADOを入手した可能性があるために同様の質問をした場合。

これは単なる獣の性質なのか、それともMSなのか。

このパターンは他のベンダーでも発生しますか?基本データアクセス戦略はどこでラップまたは変更されますか?

回答:


11

歴史的/進化的および市場の力の理由の組み合わせです

数年前にMicrosoftで働いていたとき、開発中のいくつかの異なるデータ製品があることは明らかでした。各オファリングは、特定の市場またはユースケースを対象としています。例:

  1. Accessは、フォームとレポートを使用してアプリケーションを構築できるカードインデックスシステムに慣れているデスクトップユーザーを対象としています。SQLは自然な追加でした。これはすべて、「JET」という名前の独自のローカルマシンデータベースエンジンを使用しました。最終的にJETは中止されました-ブドウのつるについての言葉は、(信頼できる)ソース管理の欠如がソースの大部分を失ったことを意味したということでした。

  2. FoxProは、リレーショナルデータよりも高速なデスクトップユーザーを対象としています。

  3. SQL Serverは、企業が必要とするすべてのスケール/電力/可用性などを備えたエンタープライズ/サーバー側の「ビッグ」データベースシステムでした。IIRC、MSは、MSSQLを構築するSybase 6のバージョンをライセンスしました。

時間が経つにつれて、境界の一部がぼやけてきました。たとえば、SQL Serverは現在デスクトップマシンで実行できますが、ユースケースは残っています。

これにより、3つの「バックエンド」、つまりMicrosoftが作成したデータベース製品が得られます。

ミックスに追加するために、これらのシステムにアクセスするためのさまざまなレベルの開発者APIが提供されました。

  1. 最初は、APIの方法はあまりありませんでした-アプリケーション(FoxPro / Access)内にコードを記述しました。VBAは1つの方法でした。

  2. MicrosoftはWindowsがOracle、Sybaseなどの大きなデータベースと通信できるように、競合するシステムに接続するためにMS ODBCを実装しました。ExcelはODBCツールを取得する注目すべきアプリの1つです。 / graphsなど。多くのデータベースベンダーは、異なるクライアントが接続できるようにODBCを実装することになりました。そのため、この戦略はある程度成功しました。ODBCは、最小公分母を表すと見なすことができます。

  3. さまざまなチームが、ローカルのDAO(データアクセスオブジェクト)やリモートのRDO(リモートデータオブジェクト)などのデータベースエンジンにアクセスする独自の方法を作り始めました。これは当時最も人気のあるMS開発者製品でした。

  4. これらの多様なAPIを合理化し、単一/統一された非常に柔軟なデータベースアクセスAPIを提供するための内部努力により、OLEDBが得られましたが、それを取得するのは非常に困難でした(多くのC ++テンプレート)。

  5. OLEDBはVBから使用できなかったため、ADOはActiveX技術を使用して開発されたため、COM、OLE、ActiveXを実行できるもの、つまりAccess、Excel、VB、したがってASPがデータベース対応になり、再利用可能になりました。

  6. .NET時代に移行すると、ADOはさまざまなメリットをもたらす.NET環境に自然に移行しました。

  7. LINQの登場により、実際のデータベースアクセスメカニズムの問題は少なくなりました。


警告-私は少し前に去ったので、私の記憶は少し曖昧です


+1 DAO、RDO、ADOの部分についての素晴らしい説明ですが、疑問が残ります。なぜパターンが繰り返されたのですか?
コンラッドフリックス

私はいつも、さまざまなMS部門が独自の(NIH)テクノロジーを考案していると考えていました。確かにそれらの膨大な数があります-そして、EFに置き換えられて以来、LINQ2SQLを忘れていました!
-gbjbaanb

5

公平を期すために、言及したものはすべてADO.NETの上に構築されています。それ以前は、ADOはしばらくの間は好まれたルートでしたが、DAOはMicrosoft Access Databaseにネイティブであったため、ちょっとぶらぶらしています。RDOは、私が言えることから到着時に死んでいた。

あなたが言及するすべての異なるフレームワークで、私は問題はすべての人に解決策を提供し、他のすべてのプラットフォームと競争しようとしていることだと思います。コードでSQLを使用する簡単な方法が必要な場合は、System.Dataに進みます。Entity Frameworkを使用してORMが必要な場合。中間の何かについては、Enterprise Library Dataを使用します。誰もが何か違うものを望んでいます。

また、MSはさまざまなアジェンダを持つさまざまなチームを持つ非常に大きな会社であるという問題もあります。たとえば、なぜ私は知っている3つのワードプロセッサも持っているのですか?


この。すべての人に適したものはないので、すべてのオプションを開いたままにします。
stijn

2

個人的には、マイクロソフト内のマーケティングの影響の結果だと思います。すべての権利によって、これらのテクノロジーのほとんどは、古いバージョンのバージョンアップグレードとして簡単にリリースできますが、データアクセスレイヤーのような基本的なものでも継続的に再発明するというこのイメージを身に付ける必要がありそうです。



0

これがまさにITの性質です!物事が変わる!Javaの世界では、JDBC、EJB 1.0、EJB 2.0、Hibernate、EJB 3.0など、同じものがありました。


1
私はJavaの専門家ではありませんが、HibernateはSunのものではないため、探していた比較ではありません。EJBはデータアクセスよりもSOAの方が多く、ソフトウェアアクセスの方が多いようです。入手できるソフトウェアスタック。統合せずに同じことをするためのいくつかの異なる方法は、どのようなアプローチが必要かを考えているようです。
コンラッドフリックス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.