这个StackOverflow问题询问“我可以在哪里获得Microsoft.Data.Objects”
事实证明，答案可能是它在Entity Framework 4的CTP4（代码优先）版本中。但是，有很多猜测。包含
10年前，如果有人问类似的问题，因为他们可能已经获得了DAO，RDO，ADO。
这只是野兽的本性还是MS。
其他供应商也会发生这种情况吗？基本数据访问策略在哪里包装或更改？
Answers:
这是历史/进化和市场力量原因的结合
几年前在Microsoft工作时，很明显，正在开发几种不同的数据产品。每个产品都针对特定的市场或用例，例如：
Access的目标用户是熟悉卡片索引系统的台式机用户，他们可以使用表格和报告来构建应用程序。SQL是自然添加的。所有这些都使用了自己的名为“ JET”的本地计算机数据库引擎。最终，JET被淘汰了-葡萄树上的一句话是，缺乏（可靠的）源代码控制意味着他们损失了很大一部分源代码。
FoxPro的目标用户是希望加快关系数据处理速度的台式机用户。
SQL Server是具有企业所需的所有规模/能力/可用性等的企业/服务器端“大型”数据库系统。在IIRC上，MS许可了用于构建MSSQL的Sybase 6版本。
随着时间的流逝，某些界限变得越来越模糊-例如，SQL Server现在可以在台式机上运行，但用例仍然存在。
因此，这给了我们3个“后端”-微软生产的数据库产品。
为了增加组合，然后提供了不同级别的开发人员API来访问这些系统：
最初，API的使用方式并不多-您在应用程序（FoxPro / Access）中编写了代码。VBA是一种方法。
微软实施了MS ODBC，以连接到竞争的系统，以便Windows可以与诸如Oracle，Sybase等大型数据库进行对话。Excel是获得ODBC工具的著名应用之一-从您的大数据库中提取数据，对其进行操作并生成产品图表/ graphs等。许多数据库供应商最终实现了ODBC，以允许不同的客户端进行连接，因此，该策略在一定程度上是成功的-ODBC可被视为代表着最小的公分母。
不同的团队开始产生自己的方式来访问数据库引擎，例如用于本地的DAO（数据访问对象）和用于远程的RDO（远程数据对象），可通过当时最流行的MS开发人员产品VB进行访问。
为了使这些多样化的API合理化并提供一个/统一的高度灵活的数据库访问API，我们进行了内部努力，这为我们提供了OLEDB，但很难（很多C ++模板）进入。
OLEDB无法在VB中使用，因此ADO是使用ActiveX技术开发的，因此它可以被可用于COM / OLE / ActiveX的任何事物重用，这意味着Access，Excel，VB和ASP都已启用数据库。
当我们进入.NET时代时，ADO自然地进入了.NET环境，带来了许多好处。
随着LINQ的出现，实际的数据库访问机制已不再是一个问题。
请注意-我前段时间离开了，所以我的记忆有些模糊
公平地说，您提到的所有内容都是基于ADO.NET构建的。在那之前，ADO是一时的首选途径，但是DAO只是徘徊不前，因为它是Microsoft Access数据库的本机。据我所知，RDO在到达时已经死亡。
在您提到的所有不同框架中，我认为问题在于它们试图为所有人提供解决方案并与其他平台竞争。如果您想要一种简单的方法在代码中使用SQL，请使用System.Data。如果要使用实体框架的ORM。对于介于两者之间的内容，请使用企业库数据。每个人都想要不同的东西。
还有一个问题是，MS是一家非常大的公司，拥有不同的团队和不同的议程。例如，为什么他们也有3个字处理器（我知道）。
我个人认为，这更多是微软内部营销的影响。保留所有权利，尽管其中的大多数技术都可以作为较早版本的版本升级轻松发布，但是似乎迫切需要这种形象，即不断重新发明甚至是基本的数据访问层。