Linq vs MS Enterprise Library DAAB

Question

在工作中，我们刚刚从VS2005升级到2010。到目前为止，我们只使用了sprocs (我猜主要是出于习惯)。我一直在尝试Linq (非常简单的教程--没什么大问题)。作为我第一次使用ORM的实际体验，我喜欢它。

此外，我最近才开始熟悉Enterprise Library块。一般来说，项目是否会使用ORM或DAAB，或者项目可能/是否会同时使用两者？这取决于情况，还是仅仅取决于偏好？有没有一种选择比另一种更好的情况？

谢谢。

Answer 1

一个或另一个..。我已经有一段时间没有使用DAAB了，但是LINQ to SQL或ADO.NET EF使用一个设计器来生成表示数据库的代码类，其中DAAB是建立在ADO.NET (数据集等等)之上的。

我喜欢LINQ，它易于使用，你可以使用存储过程来很好地获取数据，或者构造一个LINQ查询来提取数据(代码LINQ查询被转换为数据库查询)。

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

HTH。

Answer 2

我们在完全相同的点上，已经使用DAAB从2.0到4.1。FWIW这是我们的想法(我们真的是专业ORM)：

在以下两种情况之间存在权衡：

具有代码生成功能的对象关系映射提供的

• 生产力改进(特别是通过不必手动编写SProcs和LINQ提供的w.r.t.急切和延迟加载，只获取所需的列(查询的狭窄允许更好地命中NC和覆盖索引等)
• 据我们所知，LINQ使用参数化查询，因此性能w.r.t.计划缓存，不易受到SQL注入攻击http://msdn.microsoft.com/en-us/library/bb386929.aspx

然而，不利的一面是

• 失去对实体的控制-它们不一定是POCO (对于LINQ2SQL)，尽管EF4允许您自己的POCO，并且仍然可以通过对DB执行的查询中的控制/确定性的proxies.
• Lack来实现延迟加载，这意味着针对DB的覆盖测试是一个潜在的问题(尽管为POCO确定索引策略相对简单，但是您要小心，实体图的更新可能会产生意想不到的“深度”后果。LINQ2SQL确实可以将"SavesWith“类比为急切加载的"LoadsWith"

总而言之，我们对大约80%的表/实体的ORM感到满意，但随后会考虑针对真正敏感的、特定于性能的东西的自定义工作。

HTH

Answer 3

DAAB与老式的数据库访问(比如DataSets)密切相关，而像Linq这样的现代ORM更多的是关于从数据库模式生成的强类型实体。

如果您需要数据库中立性(IIRC，它非常适合用于不同类型的DBMS)，并且您希望避免严重依赖编译时魔术的工具，我只建议您使用DAAB。

form通常非常擅长以易用性和工具支持的形式交付价值。然而，它们经常与“对象关系阻抗不匹配”发生冲突，即实体在外观和行为上与表面上的标准对象相似，但由于它们抽象的RDBMS与面向对象的计算并不真正兼容，因此对它们的使用具有深远的要求。您的代码必须“知道”如何使用它们，否则将面临在编译时捕获不到的陷阱。

就我个人而言，我会避开DAAB。除了一些闪亮的例子(Unity!)EL是相当重量级的，需要做大量的工作才能正确理解和使用。它通常是一个安装在轨道上的手提钻，在那里凿就可以工作了。抛开缺点不谈，大多数ORM都非常好。Linq to Sql是可靠的，而EF4正在实现这一目标。也有开源的替代方案，比如nHibernate，它们也为学习曲线提供了很好的价值。

如果我明天要开始一个新项目，我会使用最近发布的EF4 code-first bits。我想这主要是因为我贪吃惩罚；EF4一直是我的痛处……