Linq与MS企业库DAAB比较

Question

在工作中，我们刚从VS2005升级到2010。到目前为止，我们只使用过存储过程（我想出于习惯而已）。我一直在尝试使用Linq（非常简单的教程-没有什么大不了的）。作为我第一个实际使用ORM的经验，我很喜欢它。

此外，我最近才熟悉企业库块。一般来说，项目会使用ORM或DAAB，或者可能同时使用两者吗？这取决于情况，还是只是个人偏好？是否有一种情况比另一种更好？

谢谢。

- Matt M

Answer 1

我们正处于完全相同的位置，从2.0到4.1一直使用DAAB。值得一提的是，这是我们的想法（我们真的是Pro ORM）：

在以下方面存在权衡：

- ORM具有代码生成功能，可以提高生产力（特别是不需要手动编写SProcs和实体） - LINQ在Eager和Lazy Loading方面提供了更好的灵活性，可以仅获取所需列（查询的狭窄性允许更好地命中NC和Covering索引等） - 就我们所知，LINQ使用参数化查询，因此与计划缓存相关的性能并不容易受到SQL注入攻击的影响。

然而，缺点如下：

- 对实体的控制丧失了——它们不一定是POCO（对于LINQ2SQL），虽然EF4允许您自己的POCO，并且使用代理仍然可以实现延迟加载。 - 查询可能会执行对DB的控制/确定性不足，这意味着针对DB的覆盖测试可能存在问题（而对于SPROC来说，识别索引策略相对简单）。 - 除非您小心，否则更新实体图可能会产生意外的“深度”后果。LINQ2SQL确实需要一个类似于Eager Loading“LoadsWith”的“SavesWith”类比。

总之，我们对ORM的大约80％的表/实体感到满意，但会为真正敏感的性能特定内容寻求定制工作。

- StuartLC

Answer 2

二者之一...我已经有一段时间没有使用DAAB了，但是LINQ to SQL或ADO.NET EF使用设计器生成代表数据库的代码类，而DAAB则建立在ADO.NET（DataSet等）之上。

我喜欢LINQ，易于使用，您可以使用存储过程轻松获取数据，或构造LINQ查询以提取数据（代码LINQ查询会转换为数据库查询）。

因此，我更喜欢LINQ；如果您使用DAAB，则建议使用代码生成工具。

希望对您有所帮助。

- Brian Mains

Answer 3

DAAB与早期的数据库访问方式（如DataSets）密切相关，而现代ORM（如Linq）更多地涉及从数据库模式生成的强类型实体。

如果需要数据库中立性（如果我没记错，它非常适合用于不同类型的DBMS），并且希望避免过度依赖编译时魔法的工具，我只建议使用DAAB。

ORM通常很擅长通过易用性和工具支持提供价值。但是，它们经常与“对象关系阻抗不匹配”发生冲突，其中实体在表面上看起来和行为类似于标准对象，但由于其抽象了与面向对象计算不真正兼容的RDBMS，因此对它们的使用具有深远的要求。否则，你的代码必须“知道”如何使用它们，否则会遇到无法在编译时捕捉到的陷阱。

就个人而言，我会避免使用DAAB。除了一些闪亮的例子（Unity！）外，EL相当笨重，需要相当多的工作才能理解和正确使用。它通常是一种轨道安装的压路机，而凿子可以完成同样的工作。大多数ORM都相当不错，尽管存在一些缺点。Linq to Sql很可靠，EF4也在不断完善。还有开源替代品，如nHibernate，对于学习曲线也提供了很好的价值。

如果我明天要开始一个新项目，我会使用最近发布的EF4 code-first bits。我认为这主要是因为我喜欢自讨苦吃；EF4一直是我的痛处...

- user1228