使用ADO.Net实体模型的优缺点

嗨

使用ADO.NET实体模型作为数据层的优缺点是什么？如果我要使用这种技术，我应该使用LINQ吗

谢谢。我还没找到犯人。 编辑：以及关于ADO.NET的更多信息，包括缺点：

关于LINQ：没有人会强迫你使用LINQ（也许雇主除外），但与ADO.NET结合使用肯定会有好处。另见：

---

很抱歉有这么多链接，但是C/p的文本太多了。高兴地阅读：）。

首先：您不必使用LINQ来使用实体框架（EF），但它确实有帮助。EF基于EF团队称之为实体SQL的东西，因此当您使用LINQ to Entities时，实际发生的情况是LINQ表达式被转换为实体SQL，而实体SQL又被转换为数据库使用的任何SQL方言（SQL Server的T-SQL）

EF的利弊是一个有争议的话题，因为大多数人并不特别喜欢EF，但我会尽量保持中立

专业人士

• 与LINQtoSQL（L2S）、LINQtoEntities（L2E）和EF一起，是目前Microsoft提供的最好的数据访问API。尽管存在所有缺点，但在大多数情况下，它们都比“传统”ADO.NET好得多
• 虽然L2S更简单，但L2E已被标记为Microsoft数据访问API的未来，因此如果您想继续使用主流Microsoft API slipstream，则应使用L2E。看起来L2S不会有太多新的发展
• EF将在.NET4中获得相当大的功能和灵活性提升

缺点

• 与EF合作很难。当涉及到模式更改时，它是非常脆弱的，当底层模式更改时更新它是非常困难的
• EF生成的T-SQL非常糟糕（尽管在.NET4中应该会有所改变）
• 持久性无知是不可能的（直到.NET4）
• 很多LINQ方法都没有实现，因此API的限制比看起来的要大
• 它并不像人们希望的那样灵活

---

简言之，如果您只能使用BCL中烘焙的内容，请使用它；如果您使用的是.NET4，请尝试一下；除此之外，还有更好的选择，比如开源库。

我更喜欢回答以前使用过这种技术的人以及他们遇到的困难。所以我对缺点比对优点更感兴趣。因为职业选手基本上都是RAD。好吧，这对我来说不是很清楚。实体框架不是我的专长。非常感谢这个信息丰富的答案。但我认为最好不要使用EF，除非使用.Net4。既然它是全新的，那么最好先等人们来测试它。。。微软的所有新技术都是如此。