NHibernate 映射属性与 Fluent NHibernate
映射属性是否提供与 NHIB HBM 相同的多功能性？您能否将它们与 FNH 一起使用来处理 FNH 还不能像 hbm 那样完成的事情？
干杯，
Berryl
通过映射属性，我指的不是 hbm 文件；而是指映射属性。显然，NHib（或者现在可能是 NHib contrib）附带了一些属性，您可以用它们来装饰您的类和类。类属性。我猜这些早于 FNH，但不确定。
Do mapping attributes offer the same versatility as nhib hbm's do? Can you use them together with FNH to handle things FNH doesn't yet do as well as hbm's can?
Cheers,
Berryl
By mapping attributes, I don't mean hbm files; there are apparently attributes that come with NHib (or maybe NHib contrib these days) that you use to decorate your class & class properties. I'm guessing these pre-date FNH, but not sure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我个人更喜欢自己创建 hbm.xml 文件。我使用过 Fluent，但我只是喜欢自己管理此类事情的细节。然而，我还没有遇到任何我无法使用 Fluent 进行工作的映射...
据我了解，Fluent nHibernate 实际上会根据您的设置在后台创建一个 hbm.xml 文件，该文件依次由 nHibernate 使用...因此 Fluent 本身正在创建映射，我认为仅手动创建 hbm.xml 从技术上来说会给您更大的灵活性并可以访问映射文件的细微差别...
我认为有两者的学习曲线相似，所以如果您打算学习 Fluent 本身创建 hbm.xml 文件，为什么不首先学习如何自己创建该死的 hbm.xml 文件并跳过中间人！
除非您快速连续地执行许多项目，否则实际映射数据库的行为只是您在特定项目上所做的实际工作的一部分。
I personally prefer to create the hbm.xml files myself. I've used Fluent, but I just like managing the nitty gritty myself for things like this. However I've not run into any mappings that I haven't been able to get working with Fluent though...
It is my understanding that Fluent nHibernate actually creates an hbm.xml file in the background based on your settings that is in turn used by nHibernate... so being that Fluent is itself creating the mappings, I would argue that just creating the hbm.xml manually would technically give you more flexibility and access to the nuance of the mapping file...
I think that there is a similar learning curve for both, so if you are going to bother learning Fluent that itself creates hbm.xml files, why not just learn how to create the damn hbm.xml files yourself in the first place and skip the middle man!
Unless you are doing MANY MANY projects in rapid succession, the act of actually mapping your database is only a fragment of the actual work you are doing on a particular project.
NHibernate 属性确实早于 FNH。除了一小部分顽固的坚持者之外，我真的不认识任何人使用它们。他们受到支持，但并不完全友好。如果您喜欢属性，Castle ActiveRecord 属性是比 NHibernate 核心属性更好的实现。
Fluent NHibernate 可以与其他一切一起工作。它所做的就是将映射注入 NHibernate 配置实例，因此您可以在其中放置您喜欢的任何其他内容。 ActiveRecord 是一个影响更广泛的解决方案，所以这可能是这个规则的一个例外，我已经有一段时间没有使用它了。
The NHibernate attributes do pre-date FNH. Apart from a relatively small group of die-hard holdouts, I don't really know anyone that uses them. They're supported, but not exactly friendly. If you like attributes, the Castle ActiveRecord attributes are a much better implementation than the NHibernate core ones.
Fluent NHibernate can work with everything else. All it does is inject mappings into the NHibernate Configuration instance, so you can put whatever else in there you like. ActiveRecord is a bit more of a wide-reaching solution, so that may be an exception to this rule, it's been a while since I've used it.
我从未遇到过 Fluent NHibernate 无法处理的情况，但也许您正在使用一个晦涩的属性。您有什么特别需要了解的信息吗？
I've never run into a situation that couldn't be handled by Fluent NHibernate, but maybe you're using an obscure attribute. Anything in particular you need to know is available?
我们在我的业务中使用它们，我有点喜欢它们。
我认为直接在类定义中编写映射非常巧妙（我知道 - 每个人都有自己的映射）。
We are using them in my business and I kinda like them.
I think it is really neat writing the mapping directly in the class definition (I know - to each one his own).
我同意这里的大多数评论，Hibernate 使您可以自由选择如何实现对象的映射。
我不喜欢在 NHibernate 的类上使用属性，因为现在我的类现在有另一个他们不应该知道的依赖项。
如果您想将数据源更改为 OODB 或只是一个文件，会发生什么情况。这些类将具有冗余的映射代码（属性）。在这种情况下，可以说，使用存储库实现将映射存储在数据/基础设施层中（假设使用存储库模式）更干净，
我也同意，每个人都有自己的:)
I agree with most the comments here, Hibernate gives you the freedom of choice on how to implement the maps for the objects.
I prefer not to use attributes on my classes for NHibernate, as now my classes now have another dependancy which they should not know of.
What happens if you want to change your datasouce to a OODB or just a file. The classes will have redundant mapping code(the attributes). in this case it could be said, its cleaner to store the mapping in the data/infrastructure layer with the repository implementation (assumed useage of the repository pattern)
I also agree, each to they own :)
我试图了解 NHibernate 3 在属性与注释方面与 Hibernate 3 的关系。我参与过几个 Java 项目，其中我们使用 Hibernate 3 注释进行映射。它非常优雅，因为
不确定我是否购买“如果必须更改数据源怎么办”或“关注点分离”论点。实际上，这些论点着眼于“20%”（或更少）的情况，要么不会发生，要么发生时产生边际影响——恕我直言，好处要大得多。
话虽如此，我不清楚 NHibernate 团队是否投入了足够的资金来使属性足够强大以保证使用，或者我是否最好迁移到 EF4.x 以获得相同的好处......这些是我希望从这篇文章中得到答案。
I'm trying to understand where NHibernate 3 stands in relation to Hibernate 3 with respect to attributes vs annotation. I've been on several Java projects where we used Hibernate 3 annotations for mapping. It is quite elegant as
Not sure I buy the "what if you have to change datasources" or the "separation of concerns" arguments. In practice, those arguments are looking at the "20%" (or less) that either won't occur, or have marginal impact if they do - the benefits are far greater IMHO.
With that said, what is not clear to me is whether the NHibernate team has invested enough in making the attributes robust enough to warrant use, or would I be better off moving to EF4.x to get the same benefits... those are the answers I was hoping for from this post.