为什么选择 Fluent NHibernate 与 hbm XML 文件？
虽然这是一个主观问题，但作为一名 NHibernate 新用户，我很好奇为什么人们会选择 Fluent 而不是传统的 XML 映射。
从我的角度来看，当我第一次使用 NHibernate 时，我使用了 Fluent 界面，但是遇到了一些障碍，并且很难为 Fluent 界面找到除了“玩具应用程序”之外的任何内容的足够文档，所以我学会了通过XML。
随着时间的推移，我意识到我的大部分工作都是在 XML 方面完成的，并且意识到它并不像我想象的那么可怕。因此，对我个人而言，这是一个文档质量较差且编码时间没有显着节省的情况。
话虽这么说，我可能缺少一些巨大的优点/缺点，我真的很想听听那些在使用这些工具方面有更多经验的人的一些意见。
While this is a subjective question, as a new NHibernate user, I'm curious as to why one would choose Fluent vs traditional XML mapping.
From my standpoint, when I first worked with NHibernate, I used the Fluent interface, but ran into some roadblocks and had a hard time finding adequate documentation for the Fluent interface for anything beyond a 'toy app', so I learned to handle these via XML.
Over time, I realized I did most of my work on the XML side, and realized it was not as horrific as I thought it would be. So for me personally, it was a case of poor documentation and not seeing a significant savings in coding time.
That being said, there may be some huge advantage/disadvantage that I'm missing, and I'd really like to hear some opinions from folks who have more experience in working with these tools.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
编译时安全性和重构（重命名类、属性）是从流畅映射中获得的好处之一。使用一种语言（C# 或 VB.NET）编写映射、程序代码和数据访问是另一个好处。
Compile-time safety and refactoring (renaming classes, properties) are one of the benefits you get from fluent mappings. Using one language (C# or VB.NET) to write mappings, program code and data access is another benefit.
对我来说，Fluent 的一大功能是 Automapper。
我可以使用 POCO 类定义我的域模型，（大部分）不用担心它们如何映射到关系数据库中的表的讨厌细节。
作为一名长期的 OO 开发人员和偶尔的 DB 开发人员，我更喜欢以 OO 方式进行设计。我还相信这使我能够在更高、更强大的抽象级别上工作。
自动映射还使得对领域模型的持续更改不再那么令人畏惧。
您的客户刚刚在最后一刻告诉您他们想要向数据库添加四个新列？
没问题 - 将四个新属性添加到关联的 POCO（4 行代码），然后重新映射。
减轻许多项目中不断变化的需求带来的痛苦。
For me, the big feature in Fluent is the Automapper.
I can define my domain model using POCO classes, (mostly) without worrying about the nasty details of how they will be mapped to tables in a relational database.
As a long time OO developer, and occasional DB developer, I'm much more comfortable designing in an OO fashion. I also believe that this allows me to work at a higher, more powerful level of abstraction.
Automapping also makes ongoing changes to the domain model much less daunting.
Your customers have just told you at the last minute they want to add four new columns to the database?
No problem - add four new properties to the associated POCO (4 lines of code), and remap.
Takes a lot of the pain out of the constantly changing requirements that are a fact of life on many projects.
我将添加一个对于基于通用代码库创建自定义功能非常重要的原因：
使用 Fluent，您可以覆盖映射以添加新字段。对现有（超类）映射的更改会自动合并到定制/分支中。我被迫使用 Fluent 来避免为每个客户维护单独的 .hbm/xml 文件。很高兴我做到了:)
I'll add a reason that is very important for making custom functionality based on a common code base:
With fluent you can override mappings to add a new field. Changes to the existing (superclass) mappings are automatically incorporated into the customization/branch. I was forced to use Fluent to avoid maintaining a seperate .hbm/xml file for each customer. Glad I did :)
与许多开源软件一样，该库在许多功能准备好投入生产之前就已向公众开放。根据您使用的 FluentNhib 版本，某些功能可能根本没有实现。例如，当我第一次开始使用它时，复合键尚未实现，我发现了一个又一个的绊脚石。
但该产品已经发展成为一个非常出色的工具。与 xml 相比，它的功能相当完整，并且提供了其他人已经概述的所有优点。
Like a lot of open source software, this library was available to the public before a lot of the features were production ready. Depending on what version of FluentNhib you were working with, some features may not have been implemented at all. For example, when I first started working with it, composite keys had not been implemented yet and I found stumbling block after stumbling block.
But the product has evolved into quite a great tool. It's pretty feature complete compared to xml and provides all the benefits others have outlined already.