LLBLGEN Pro 和 EF4 ORM 比较
新的一年-新的开始:) 我们选择 ORM。去年我亲自与 LLBLGEN 合作。 我今天浏览了 EF4，发现它的功能与 llblgen 接近。 （过滤、排序、分组、使用存储过程和函数、使用对象图（预取路径）、lazyLoad）。
我知道 llblgen 不支持 POCO，这意味着需要编写额外的（或更复杂的）代码来将其与 Domain 解耦。
我不认为 llblgen 许可证是骗人的，因为 llblgen 是 Microsoft Orms 真正成功的替代品，而且我们有这样的替代品很酷。
我在 stackoverflow 中没有找到这些 orms 的具体比较。 就像“如果支付 maney 并不重要，那么使用 llblgen”:)。
所以我只想列出 LLBLGEN 和 EF4 的优缺点。 （只有 ORM 功能，没有设计器功能）
New year - new startup :)
We are chosing ORM. I personally worked with LLBLGEN last years.
I've looked through EF4 today and have found that its functionality is close to llblgen.
(filtering, sorting, grouping, working with stored procedures and functions, working with graphs of objects (prefetch path), lazyLoad).
I know that llblgen doesn't support POCO, that means that it is required to write additional (or more complex) code to decouple it from Domain.
I don't think that llblgen license is con as llblgen is real successful alternative to Microsoft's orms and it is cool that we have such alternatives.
I didn't find any concrete comparison of these orms in stackoverflow.
Just something like "If it is not critical to pay maney then use llblgen" :).
So I just want to list pros and cons of LLBLGEN and EF4. (ORMs functionality only without designers features)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
过去几年，我在多个项目中使用了法学学士学位，并且刚刚完成我的第一个 EF4 项目。
两者都非常适合对象表之间的简单 1-1 映射。毫无疑问，其他人会不同意，但对于我使用 codegen 的项目，我会尽力保持这种情况。
我不是 EF4 专家，所以它可能有一些我还没有发现的功能，但我觉得 LLB 是一个更成熟的产品，而且支持绝对很棒。
令人惊讶的是，获得有关 EF4 的帮助远没有那么容易，而且在谷歌上搜索答案可能很困难，因为您最终会得到大量不相关的 C# 搜索结果。法学学士论坛往往会非常快地为您提供代码片段的详细答案 - 通常在几个小时内。
但 MS 是个庞然大物，我不得不在一个项目中尝试 EF4，而且一切进展顺利。但我个人还是更喜欢LLB。
I have used LLB on several projects over the last few years and I am just finishing off my first EF4 project.
Both are perfectly fine for simple 1-1 mappings between objects-tables. Doubtless other people would disagree, but for projects where I use codegen I try and keep that the case as far as possible.
I'm no EF4 expert, so theres probably things it can do that I've not discovered yet but I feel that LLB is a more mature product and the support is absolutely fantastic.
Surprisingly enough getting help on EF4 is nowhere near as easy and googling for the answers can be difficult because you end up with loads of unrelated C# hits. The LLB forums tend to give you detailed answers to your code snippets very quickly - normally within hours.
But MS being the huge beast that it is I had to give EF4 a try on a project, and things have worked out fine. But personally I still prefer LLB.
Pro for LLBLGen - 支持。响应速度非常快的支持论坛，问题通常会在一天或两天（有时是几个小时）内得到解决。
尝试获得对 EF 的支持级别（或任何其他 ORM 达到此水平！）
Pro for LLBLGen - support. Very responsive support forum with issues typically fixed in a day or 2 (or sometimes hours)
Try getting that level of support for EF (or any other ORM come to that !)
好的，伙计们。我来总结一下学习EF4后我的问题。
可以将 EF4 与 POCO 对象一起使用，如果您正在使用域模型，这会很好。 LLB 不支持 POCO。
即使没有 dataContext（适配器场景），LLB 实体也具有状态。这意味着您可以在一个上下文中获取实体并将其保存在另一个上下文中，第二个上下文将知道该实体不是新的。 EF4 会将其视为新实体，并且需要编写额外的代码将其标记为已更新。
LLB 具有适合小型应用程序的 SelfServicing 方案，因为实体具有自我保存和延迟加载功能。
如上所述，LLB 得到了很大的支持。好像规定是工作日8小时回答，周末24小时回答。
Ok guys. Let me summarize my question after studying EF4.
It is possible to use EF4 with POCO objects that is good if you are working with Domain model. LLB doesn't support POCO.
LLB entities has state even without dataContext (Adapter scenario). It means that you can get entity in one context and save it in another and second context will know that entity is not new. EF4 will treat it as new Entity and it is require to write additional code to mark it as updated.
LLB has SelfServicing scenario that is good for small applications as entities have self saving and lazy load functionality.
As mentioned above, LLB has great support. It seems the rule is to answer during 8h in workdays and 24h in weekends.
LLBLGen 非常成熟，它生成的代码大约是所需代码的六倍。请记住，它的第一个令人困惑和过于复杂的 API 早在泛型和 LINQ 引入之前就已经设计好了，它表明了这一点。只有当您已经投入多年的时间来学习它时，使用 LLBLGen 开始一个新项目才是可以理解的。在所有其他情况下，帮自己一个忙，忘记它曾经存在过！
LLBLGen is so mature that it generates about six times as much code as necessary. Keep in mind that its first of many confusing and overcomplicated APIs had been designed long before the introduction of generics and LINQ and it shows. Starting a new project using LLBLGen is only understandable if you have already invested years in learning it. In all other cases do yourself a favor and forget it ever existed!