LLBLGEN Pro和EF4 ORM比较

Question

新年 - 新创业:) 我们正在选择ORM。去年我亲自与LLBLGEN合作过。 我今天看了EF4，发现它的功能接近于llblgen。 （过滤，排序，分组，使用存储过程和函数，使用对象图（预取路径），lazyLoad）。

我知道llblgen不支持POCO，这意味着需要编写额外的（或更复杂的）代码才能将其与域分离。

我不认为llblgen许可是骗局，因为llblgen是微软公司的真正成功替代品，而且我们有这样的替代方案很酷。

我没有在stackoverflow中找到这些orms的具体比较。 就像“如果支付maney并不重要，那么使用llblgen”：）。

所以我只想列出LLBLGEN和EF4的优点和缺点。 （只有没有设计师功能的ORM功能）

Answer 1

过去几年我在几个项目中使用了LLB，我刚刚完成了我的第一个EF4项目。 对于对象表之间的简单1-1映射，两者都非常好。毫无疑问，其他人会不同意，但对于我使用codegen的项目，我尽量保持这种情况。 我不是EF4的专家，所以它可能做的事情我还没有发现，但我觉得LLB是一个更成熟的产品，而且支持绝对是太棒了。 令人惊讶的是，获得EF4的帮助远远不够容易，谷歌搜索答案可能很困难，因为你最终会遇到大量不相关的C＃命中。 LLB论坛倾向于非常快速地为您提供代码片段的详细答案 - 通常在几小时内。

但MS是一个巨大的野兽，我不得不试试EF4项目，事情已经很好了。但我个人还是喜欢LLB。

Answer 2

ProBL for LLBLGen - 支持。非常敏感的支持论坛，通常在一天或两天（或有时几小时）内修复问题

尝试获得对EF（或任何其他ORM的支持）的支持级别！）

Answer 3

好的伙计们。让我在研究EF4后总结一下我的问题。

1. 如果使用域模型，可以将EF4与POCO对象一起使用。 LLB不支持POCO。

2. 即使没有dataContext（适配器方案），LLB实体也具有状态。这意味着您可以在一个上下文中获取实体并将其保存在另一个上下文中，第二个上下文将知道该实体不是新的。 EF4会将其视为新实体，并且需要编写其他代码以将其标记为已更新。

3. LLB具有SelfServicing场景，适用于小型应用程序，因为实体具有自我保存和延迟加载功能。

4. 如上所述，LLB有很大的支持。似乎规则是在工作日的8小时和周末的24小时回答。

Answer 4

LLBLGen非常成熟，它产生的代码大约是必要的六倍。请记住，在引入泛型和LINQ之前很久就已经设计了许多令人困惑和过于复杂的API中的第一个。使用LLBLGen开始一个新项目只有在你已经花了多年时间学习它才能理解。在所有其他情况下，帮自己一个忙，忘记它曾经存在过！