NHibernate mapping attributes vs fluent NHibernate

Question

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.

Retrusion

Answer 1

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.

• Max Schilling

Zea

Agreed. The xml-o-phobic in me resisted learning hbm's but you really won't be fluent until you do. I am talking about the attributes that are an alternative, or were, to both FNH and hbm files. Cheers – Retrusion

Max: So why not write raw SQL yourself? That's all NHibernate generates in the end. It's the abstraction that benefits you in both NHibernate's case, and FNH's mappings. Sure, all FNH does is generate hbms, but it also simplifies the process of doing so and gives you greater control at a higher-level. I agree entirely that mapping is a tiny part of an application development process, but surely it's better to make it an even smaller amount? – Mattheus

I think it boils down to choosing your abstractions. The SQL part is a major piece and nHibernate saves significant time over writing SQL, but for the mapping I don't know... I like Fluent automapping for quick scaffolding but I don't agree about better control. If the law of leaky abstractions holds true, and with Fluent being an abstraction of an abstraction then my preference is to go with the closer to the metal approach if possible. I'm just as comfortable with the hbm.xml and I don't find them more complex than Fluent. Its just different instructions to achieve the same result. – Zea

Answer 2

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.

Mattheus

I thought as much. "NHib In Action" gives them significant air-time and thus credibility, while saying FNH is a promising work-in-progress, something other NHib experts like Ayende, Fabio & Steve Bohlen seem to say when they say it. While the book is clearly dated in details the scope it covers is more sophisticated than anything else I've seen so far. I don't know how to bridge my knowledge gaps other than by asking "dumb" questions here on SO and NHib / FNH forums. Nature of the complicated beast IMO, but you are clearly filling a gap in the community that is appreciated by many. Cheers – Retrusion

One thing you need to bare in mind is that NHibernate in Action was published over a year ago, content frozen quite a bit before that, and based on the 1.x releases of NHibernate. Whilst that doesn't affect the quality of it's content, lots has changed since then. – Mattheus

Also of note, Fluent NHibernate will never support every single possible mapping that NHibernate supports, because an awful lot of those mappings are there to support peculiar edge-cases. It's the 80/20 rule, we support the 80% that people use the most, the rest can always be done in hbm. – Mattheus

Right; which is why it is reasonable for a consumer to understand what the missing 20% is and how best to provide it when needed. The question here is to see to whether mapping attributes are worth exploring as a means to just that end. Your answer would clearly be no sir, do that in an hbm. Cheers – Retrusion

Answer 3

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?

Snooze

I currently only use FNH too, and didn't even know about mapping attributes until reading Manning's NHib in Action, so this question is more about them than FNH. BUT one thing I have trouble with FNH is that it won't let me set discriminator column names and values (it uses defaults that work but aren't what I want). Cheers – Retrusion

Berryl, I think you need to raise a support issue about your discriminator problem because FNH most definitely does let you specify both the discriminator column name and values. – Mattheus

@James - I actually did raise a support issue, got no response and saw other posts on the same issue from other users since then. See support issue raised March 26, 2010 @ 11:07 AM "converting table-per-subclass to table-per-class-heirachy" (2nd post) and this thread groups.google.com/group/fluent-nhibernate/browse_thread/thread/… started Mar 9th. Cheers – Retrusion

Answer 4

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).

Whisler

Answer 5

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 :)

Auspex

Agreed - I was just wondering if they offered any more hbm equivalent 'power' than FNH, which I am going to use to to get the 80% done in any event. Underlying there is the question of what exactly hbms can do that FNH currently cannot. Cheers – Retrusion

Thats cool, I thought you were considering Attributed mappings. one exellent thing about FNH it allows you to convert you fluent mapping into the old XML, incase you do find something it does not do (fyi i have yet to find something it cannot do). im guessing you know this – Auspex

Answer 6

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

1. the entitites are clearly documented where the code lives
2. easier to debug when stepping through the debugger...
3. you don't have to go open a separate file out of context
4. less artifacts to manage
5. compile time checking
6. intellisense = fewer typos
7. no need to install/learn a separate 3rd party component (e.g. FNH)
8. the Hibernate team invested in making annotations easy to use and integral

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.

Revolution

FNH still adds a lot which Attributes can't handle: 1) Automapping 2) Conventions (for auto and manual) 3) discoverablility (through fluent interface) – Perdita