Microsoft 试图通过所有这些数据访问策略解决什么问题？
微软似乎推出了许多不同的数据访问策略。 有“经典”ADO.NET、Linq2Sql、ADO.NET 实体框架、ADO.NET 数据服务、ADO.NET 动态数据。 我确信我错过了一些。 在我看来，每个框架在应用程序架构中的位置似乎存在很多混乱。 Microsoft 试图通过所有这些数据访问方法解决什么问题？
There seems to be many different data access strategies coming out of Microsoft. There’s ‘classic’ ADO.NET, Linq2Sql, ADO.NET Entity Framework, ADO.NET Data Services, ADO.NET Dynamic Data. I’m sure that I’ve missed some. To me, it seems that there’s a lot of confusion surrounding where each frameworks fit into an application's architecture. What problem is Microsoft trying to solve with all of these data access methods?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不明白这个问题的意义。 事实上，这有点恶搞。
这些区别非常明显，只需进行少量研究就可以清楚地了解它们。
I don't see the point of this question. In fact, it's a bit trollish.
The distinctions are clear enough that a trivial amount of research would have made them clear.
他们正在努力解决如何增加销量和市场份额的问题。 为此，微软内部的各个小组试图解决如何让更多的开发人员和最终用户使用他们的产品的问题。 不同的团队提出了不同的技术，与任何大公司一样，微软努力保持其技术的一致性，并让团队朝着同一目标努力。 此外，随着新技术的出现，他们需要保持（或者更好的是，设定）步伐，并继续支持客户投资的旧技术。对于任何类型的相当大的公司（包括微软）来说，最终结果都是技术选择的选择有些混乱。
They are trying to solve the problem of how to increase sales and market share. To that end various groups within Microsoft try to attack the problem of how to get more developers and end-users using their products. Different groups come up with different technologies and like any big company, Microsoft struggles to keep it's technologies aligned and groups working toward the same end. Additionally, as newer technologies come along they need to keep (or better yet, set) the pace as well as continue to support older technologies that their customers have invested in. The end result for any sort of reasonably large company, including Microsoft, is a somewhat muddled selection of technology selections.
他们多年来一直制定数据策略。 事实上，您可以而且应该搜索“Microsoft 数据访问策略”，您会找到新旧链接（即 1998 年及其 OLEDB 策略）。
我认为您正在寻找的是 这里从 2007 年开始，尽管已经有 2 岁了，但它是关于 XML、ADO.NET、数据、LINQ、SQL Server、Visual Studio Orcas、Entity Framework...他们解决了这个问题 Microsoft 是否有数据访问策略吗？：
我希望它有所帮助。
They have had a data strategy for ages. In fact you can and should search "Microsoft Data Access Strategy" and you will find links old and new (i.e. year 1998 and their OLEDB strategy).
I think what you are looking for is here from year 2007 that even though is 2 years old is about XML, ADO.NET, Data, LINQ, SQL Server, Visual Studio Orcas, Entity Framework...they address the question Does Microsoft have a Data Access Strategy?:
I hope it helps.
你的困惑就是我们的挫败。 我们中的许多为我们的网站做出这些架构决策的人都对微软在这个问题上缺乏清晰度和良好的开发实践表示不满。
我的团队确实被 Linq2Sql 烧伤了。
我们现在使用领域驱动设计方法，特别是巴勒莫的洋葱架构（ http://jeffreypalermo.com/blog/the-onion-architecture-part-1/）。 业务对象只是 POCO，不依赖于基础设施。
基础设施现在由 NHibernate 和我们的 CMS 的定制 ORM 处理。 社区将继续将 NHibernate 推向最佳方向，并且我们控制着 ORM 的源代码，这一点远远超过了这些痛苦的启动成本。 更糟糕的是，微软确实发布了一些在 DDD 架构中工作的真正引人注目的东西，我们只需要重写我们的基础设施层。
You confusion is our frustration. A lot of us who make these architectury decisions for our websites have thrown our hands up with Microsoft's lack of clarity and good development practices on this issue.
My team certainly got burned by Linq2Sql.
We now build our website with a Domain Driven Design approach and specifically Palermo's Onion Architecture (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/). Business objects are just POCOs and have no dependencies on infrastructure.
The infrastructure is now handled by NHibernate and a custom rolled ORM for our CMS. The painful startup costs for these have been far outweighed by the knowledge that the community will continue to move NHibernate in the best direction and we control the source to our ORM. Worse comes to worse and Microsoft does release something really compelling that works in a DDD architecture, we just need to rewrite our infrastructure layer.
我在 http://msdn.microsoft.com/en-us 找到这篇文章如果您不熟悉底层概念，/magazine/cc700331.aspx 是一个很好的实体框架技术介绍。
以下是与此问题相关的部分，解释了 EF 的一些目标以及与 ADO.Net 的关系...
I find the article at http://msdn.microsoft.com/en-us/magazine/cc700331.aspx a nice technical introduction to Entity Framework if you're not familiar with the underlying concepts.
Here is a section that is relevant to this question explaining some of EF's goals and relationship to ADO.Net...