1

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

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

我不认为 llblgen 许可证是骗局的，因为 llblgen 是微软 orms 的真正成功替代品，我们有这样的替代品很酷。

我在stackoverflow中没有找到这些orms的具体比较。就像“如果付钱不重要，那就使用 llblgen”之类的东西：)。

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

4

4 回答 4

4

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

但是 MS 是一个巨大的野兽，我不得不在一个项目上尝试 EF4，而且一切都很好。但就我个人而言，我还是更喜欢 LLB。

于 2011-01-05T13:07:32.870 回答
1

Pro for LLBLGen - 支持。响应速度非常快的支持论坛，通常会在一天或两天（或有时数小时）内解决问题

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

于 2011-01-04T12:09:21.567 回答
1

好，朋友们。让我在学习 EF4 后总结一下我的问题。

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

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

  3. LLB 具有适合小型应用程序的自助服务方案，因为实体具有自我保存和延迟加载功能。

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

于 2011-01-26T14:10:42.707 回答
1

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!

于 2014-02-04T19:55:38.333 回答