Linq与MS企业库DAAB之比较

我喜欢LINQ,易于使用,您可以使用存储过程来获取数据,或者构造LINQ查询来提取数据(代码LINQ查询转换为数据库查询)。

我们在同一点上,使用了从2.0到4.1的DAAB。这是我们的想法(我们真的很赞成):

以下两者之间存在权衡:

• 具有代码生成功能的ORM可以提高生产率(特别是不必手工编写存储过程和实体代码)
• LINQ提供了w.r.t.渴望和延迟加载的灵活性,只获取所需的列(查询的狭窄性允许更好地命中NC和覆盖索引等)
• 据我们所知,LINQ使用参数化查询,因此性能w.r.t.计划缓存,不易受到SQL注入攻击 http://msdn.microsoft.com/en-us/library/bb386929.aspx

然而,在不利的一面

• 失去对实体的控制-它们不一定是POCO(对于LINQ2SQL),尽管EF4允许您自己的POCO,但是通过代理仍然可以实现延迟加载。
• 查询中缺乏控制/确定性 能够
• 除非小心,否则实体图的更新可能会产生意外的“深度”后果。LINQ2SQL真的可以用“SavesWith”来比喻急切地加载“LoadsWith”

总而言之,我们对80%的表/实体使用ORM感到满意,但是接下来我们将研究真正敏感的、特定于性能的东西的定制工作。

HTH公司

DAAB与旧的数据库访问风格(比如数据集)密切相关,而像Linq这样的现代orm更多地是从数据库模式生成的强类型实体。

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

就我个人而言,我会避开DAAB。除了几个光辉的例子(团结!)EL相当重,需要大量的工作才能正确理解和使用。它通常是一个轨道安装的凿子可以工作的手锤。除了缺点之外,大多数ORM都非常好。Linq到Sql是可靠的,EF4正在实现这一点。还有一些开源的替代品,比如nHibernate,也为学习曲线提供了很好的价值。

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