NHibernate与llblgen pro比较

我都用过了。起初,我被卖给了NHibernate,尽管我知道其他的选择,但拒绝尝试任何其他的选择。

对于llblgen pro,我很怀疑,但很快也看到了它的优势。我还没有完全放弃氨气。我将继续把int保存在我的“工具盒”中。我发现llblgen在某些情况下很有用,特别是在与已经存在的数据库进行交互时,您没有选择重新设计它。从数据库生成llblgen实体对象只需不到一个小时(当然,这取决于数据库的大小),而不必使用nhibernate手动对所有对象进行编码,并进行映射。nhibernate缺少创建映射的良好图形界面。当数据库中有数千个表,您可能需要在应用程序中访问这些表时,这一事实变得更加重要。

尽管llblgen更像是一个数据访问层生成器(我通常不喜欢dal生成器),但它有许多“真正的ORM”工具所具有的特性。在我看来,它是两全其美的。一旦你开始使用它,你就开始意识到它是非常灵活和可扩展的。我非常喜欢的一个部分是,我可以为生成的实体对象创建分部类,在那里我可以在业务逻辑中进行编码,以及进行验证。

代码生成是模板化的,因此您可以完全控制它生成的代码。有了NHibernate,我发现自己一遍又一遍地写着同样的代码。有了llblgen,我可以更快地生成它并关注业务逻辑和问题。

对于刚开始使用ORM类型工具的人,我真的建议从llblgen开始,因为nhibernate可能是压倒性的。最终你会得到同样的结果(或多或少)。

编辑第1页: llblgen现在也100%支持Linq。(因此,如果您出于这个原因喜欢linq to sql),进一步的llblgen可以支持许多数据库,其中linq to sql仅用于Microsoft SQL数据库。

编辑第2页: According to Graviton 您可以使用codesmith为nhibernate生成一些代码。这真的很酷,但对于一个新来的ORM,我仍然会推荐llblgen。对我来说,这是在llblgen将其全部包含在一个包中时添加更多依赖项。就像我之前说的那样,学习曲线的陡峭程度要低得多,你也会得到同样的好处,如果你决定去那里的话,这也会帮助你轻松地适应NHIBERNATE。

主要区别在于llblgen是一个代码生成器,而nhibernate是一个“真正的”ORM库。

llblgen优势 :

• 易于使用的模型设计器。可以导入现有的数据库架构
• 全类型对象模型和查询语言

llblgen缺点 :

• 您需要设计器应用程序来更改您的模型
• 不自由
• 因为生成了很多代码,所以会使代码膨胀

NHiberinate优势 :

• 不需要设计器应用程序。唯一代码
• 广泛使用(基于最流行的Java ORM,Hibernate)
• 对于映射任何您可以想象的数据模型都非常强大
• 开放源代码

NHiberinate缺点 :

• 难学
• 没有你想要的强类型(特别是查询)

当然,这只是我个人的观点…

我打了一个相当长的答案,才意识到这是一个有点老的问题。哦,好吧。它仍然很相关。

您已经将您的列表缩小到了.NET世界中ORM的两个最佳候选。我在这两方面的经验都很有限,但我已经广泛阅读了这两方面的利弊。它们确实以不同的方式满足不同的需求。

在即将推出的llblgen pro 3.0中,FransBouma讨论了如何添加特性来生成NHibernate映射。所以,这不一定是一个非此即彼的决定。

如果您想进行“类优先”设计(与“数据库优先”设计不同),nhibernate现在几乎是您最好的,也是唯一的选择(llblgen pro和entity framework都不支持这种模式,尽管听起来entity framework正在改进它在下一个版本中的支持)。

nhibernate和llblgen-pro都在努力与传统数据库进行良好的合作,而这些数据库是您无法更改的,必须与之共存的。这是他们的共同力量。他们都与Linq合作。它们都支持一定数量的图形化建模,尽管llblgen-pro在这方面非常优越。( ActiveWriter for NHibernate 感觉像是Visual Studio中的LinqToSQL设计器,但实际上并不是功能丰富的)。

llblgen pro具有更强的代码生成能力,但是过多的代码生成会导致测试性和可维护性受损(一个小的调整会导致大量代码需要重新测试)。

虽然nhibernate希望帮助您处理相当复杂的对象/关系映射场景,如类继承,但llblgen pro实际上只是以非常快的方式将数据库作为数据层和业务对象公开。

如果你能购买llblgen pro并有一些时间,我会尝试两者,看看哪一个更好地满足你的需要。不管怎样,学习这两种形式对你的简历都有好处。

所以,最后,我会说这是情境性的。在大多数情况下,NHiberinate的成本及其严重缺陷的缺乏是一个非常引人注目的案例。

新版本的llblgen pro(3.0)允许您为nhibernate生成代码,因此无需选择:)。它还允许您将实体拆分为不同的域。

不过,我还是更喜欢llblgen pro运行时,linq解释器更完整,而且它对字段有更好的更改跟踪。

不幸的是,新的llblgen pro 3.0运行时中没有很多新功能,因为创建者首先希望更多地关注工具而不是改进现有框架。

我使用过nhibernate、llblgen pro,这是我的咨询公司、企业库和Linq的自定义数据层。到目前为止,llblgen是我最喜欢的,它允许编写一个业务层,可以使用相同的代码与不同类型的数据库通信,从而提供数据库独立性!另一个令人难以置信的特性是它允许多个连接到不同的数据库。这在大型公司非常有用,一个系统是用SQL Server编写的,另一个需要与之交互的系统是用Oracle编写的。

llblgen-pro是一个由frans支持的令人惊叹的产品,frans非常活跃并且努力解决问题。llblgen就像photoshop,它是一个令人难以置信的工具,它可以在一个知道如何使用的人手中产生惊人的效果。和任何节省大量时间的工具一样,学习如何使用它需要一到两周的时间,但在您的项目上可以节省几个月的时间。

它不仅加快了我的应用程序的DAL生成速度,而且很容易在业务层创建查询并发送到表示层。它使创建企业级应用程序变得容易。

如果你真的想使用nhibernate,从llblgen pro开始,生成nhibernate代码。如果您的部门稍后决定从NHIBERNATE切换到LINQ,您将得到保障。是否要从SQL Server切换到Oracle?使用llblgen这是可能的,而且相对容易,而使用手工编码的nhibernate代码,您必须重写几乎不可能成本合理的所有内容。

弗兰斯也来了,回答了我的一些问题。

别忘了Hibernate最大的优点之一:hql。使用hql,您的SQL技能不会被浪费。Hibernate还为本机查询提供了非常好的无缝支持。 如果您有一些奇怪的、不标准的数据库,几乎可以肯定您在某个时候需要您的SQL技能,并且祝您在LLBL上好运!

对我来说,它归结为以数据库为中心(llblgen pro)和以域模型为中心(nhibernate)。

因为我是一个DDD/OO人,所以我的选择总是很容易的,但我明白为什么llblgen pro很受欢迎。

我们在工作中使用llblgen,它被修改了——也就是说,因为我们有多个类似的模式,但是您需要为每个模式使用不同的dll/类库,这意味着编写可以针对任何模式的代码会变得很烦人。

当然,这是一个不寻常的环境,所以它可能不适用于你。