NHibernate 还是 Fluent NHibernate?

发布于 2024-08-03 11:26:56 字数 95 浏览 7 评论 0原文

我有兴趣听取其他人关于他们是否会选择哪个(请不要选择“两者”;)以及为什么的意见。

使用 Fluent 的缺点是什么? (也许版本依赖?) 优点、缺点、经验等。

I would be interested in hearing op opinions from others regarding whether which they would choose (no 'neithers' please ;), and why.

What are the downsides to using fluent? (version dependancy maybe?)
Pros, Cons, Experiences etc.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

十秒萌定你 2024-08-10 11:26:56

Fluent NHIbernate 位于 NHibernate 之上,因此它并不是两者之间的真正选择。如果您打算使用 NHibernate,请选择在其之上使用 Fluent NH,以节省大量精力。

Fluent NHibernate 非常棒,没有它我就不会使用 NHibernate。您可以流畅地映射所有实体(为您提供编译时检查和自动化测试支持),而不必维护繁琐的 xml 文件并记住它们的语法/DTD。

它还可以根据默认和/或您自己的自定义约定自动映射您的实体。

就用它吧!

Fluent NHIbernate sits on top of NHibernate, so its not really a choice between the two. If youre going to use NHibernate, CHOOSE to use Fluent NH on top of it to save yourself vast amounts of effort.

Fluent NHibernate is awesome, I wouldn't use NHibernate without it. You can fluently map all your entities (giving you compile time checking, and automated testing support) instead of having to maintain cumbersome xml files and remember their syntax/DTD.

It can also automatically map your entities based on default and/or your own custom conventions.

Just use it!

林空鹿饮溪 2024-08-10 11:26:56

我肯定会说使用 Fluent-nhibernate。请注意,旅程可能不一定像您希望的那样顺利。

  1. 关于版本依赖

    1. 升级到新版本的 FNH 时,我遇到了“反向”依赖性问题,需要我升级到新版本的 NH(我认为是 2.0 到 2.1)。这对我来说不是一个主要问题。
    2. 我最近(今天早上)将 NH 2.1.1 放入 FNH 1.0 RTM(与 2.1.0 一起分发),没有任何戏剧性(还)。
  2. 编辑:自从写这篇文章以来,FNH 已经成熟到我认为这不再是一个真正的问题的程度
    映射支持 - 一些映射尚无法通过 fluid nhibernate 实现。然而,这并不是避免使用 FNH 的原因,因为混合 fluid-xml 映射允许您在 fluid 无法映射传统 xml 的情况下回退到传统 xml(尽管这仅在每个类的粒度上)。映射示例:

      <罢工>

    1. 尚无法映射字段 - http://groups.google.com/group/ Fluent-nhibernate/browse_thread/thread/a7787927dafd23a/84ce2616946a18d7
    2. 无法映射字典的某些时间http ://groups.google.com/group/ Fluent-nhibernate/browse_thread/thread/d38b6c72250cd2fb - 实际上,据我所知,此功能存在,但尚未在主线中。
  3. 复合复杂性因素。从它的声音中,您将同时学习 FNH 和 NH。对于大多数相当简单的应用程序来说,这很好 - 事实上 FNH 通常非常好,以至于您几乎不需要了解 hbm.xml 映射。但如果你想做一些相当复杂的事情,第一次很少会成功,你会想知道这是 PEBKAC、Fluent 还是 NH 问题。我最终编写传统的 xml 映射的次数比我希望的要多(当然,无论如何您都会这样做,但最好不要先花更多的精力去摆弄 Fluent)。

I would definitely say go with fluent-nhibernate. Just be aware it may not necessarily be as smooth a ride as you would hope.

  1. Regarding version dependency

    1. I have had a 'reverse' dependency issue when upgrading to a new version of FNH required me to upgrade to a new version of NH (2.0 to 2.1 I think). This was not a major issue for me.
    2. I just recently (this morning) dropped NH 2.1.1 into the FNH 1.0 RTM (this is distributed with 2.1.0) without any dramas (yet).
  2. Edit: Since writing this post FNH has matured substantially to the point where I do not think this is a real issue anymore
    Mapping support - some mappings are not yet possible with fluent nhibernate. However, this is NOT a reason to avoid FNH as hybrid fluent-xml mappings allow you to fallback on traditional xml in the event of fluent being unable to map it (although this is only on per-class granularity). Examples of mappings:

    1. Cannot yet map fields - http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/a7787927dafd23a/84ce2616946a18d7
    2. Cannot map some times of dictionary http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/d38b6c72250cd2fb - actually from what I gather this functionality exists but is not in the mainline yet.
  3. Compound complexity factor. From the sounds of it you will be learning both FNH and NH at the same time. For the majority of fairly simple applications this is fine - infact FNH is often so good that you need to know fairly little about the hbm.xml mappings. But if you want to go do something reasonably complex, it will rarely work the first time round and you are left wondering if it is a PEBKAC, fluent or NH issue. More often than I'd hoped I ended up writing the traditional xml mappings (of course, you are doing this anyway, but it would have been preferable not to expend more effort than necessary fiddling with fluent first).

天生の放荡 2024-08-10 11:26:56

将 Fluent NHibernate 与 NHibernate 一起使用的优点是,如果您搞乱了映射,则会出现编译时错误,而不是运行时错误。重构代码时,您还会获得更好的体验,因为您的映射会在您重命名属性或其他操作时保持最新,而不必记住手动修改 XML 映射文件。

Fluent NHibernate 最大的缺点是它仍处于开发的早期阶段,随着框架开发的进展,存在很大的破坏性风险。

The advantage of using Fluent NHibernate together with NHibernate is that you get compile time errors if you have messed up your mapping, instead of runtime errors. You also get a much better experience when refactoring your code, since your mappings are kept up to date as you rename properties or whatever, instead of having to remember to manually modify you XML mapping files.

The biggest downside of Fluent NHibernate is that it is still in a quite early phase of its development, and there is quite a big risk of breaking changes as the development of the framework progresses.

后知后觉 2024-08-10 11:26:56

就我个人而言,我并没有真正深入了解 Fluent nhibernate,因为我对映射文件很满意。使用 Visual Studio 创建映射文件非常简单,您可以设置 xml 文件的架构,从而为您提供映射文件的智能感知。我同意编译时语法检查比使用 Fluent-nhibernate 更有优势,但当我已经熟悉 XML 映射时,我很难证明学习 Fluent API 的合理性。也许我应该克服我的冷漠并学习它......:-)

Personally I havent really gotten much into fluent nhibernate as I am comfortable with the mapping files. using visual studio to create the mapping files is a breeze and you can set the schema for the xml file which gives you intellisense on the the mapping file. I agree that having compile-time syntax checking is an advantage to using fluent-nhibernate, but I struggle justifing learning the fluent API when I already am familiar with the XML mapping. Perhaps I should just get over my lethergy and learn it already... :-)

九命猫 2024-08-10 11:26:56

Fluent N-Hibernate 确实是 NHibernate 的一个很好的包装。 Fluent 中的映射管理比 xml 映射要好得多。当您掌握 Fluent 时,开发就会变得很快...

如果您使用 Entity Developer 来创建实体和数据库模式,那就最好了。

Fluent N-Hibernate is really a nice wrapper over NHibernate. To manage mapping in Fluent much better than xml mapping. Development become fast as you get on to Fluent...

Best if you use Entity Developer for creating entity and Database schema.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文