+972 52-548-6969
Choosing between Active Record, Fluent NHibernate and NHibernate
I have seen videos where you created a domain model using ActiveRecord in real-time... elaborate on when and how you move to using full Hibernate in more detail.
The problem with presentations such as the one described in the question is that they are cheating. Oh, I really do work things on the fly, but it is like asking me to type with my eyes closed (as I am doing right now, just to see if I can).
I can do that, but it doesn’t really say much about my typing skills. The type of models that I create live tend to be very simple ones, things that I have done for dozens and hundreds of times. Building a model live on stage looks impressive, especially since I insist of the people in the audience picking the model. But it really isn’t that hard.
That said, the actual question is more interesting, what should you choose? Active Record, Fluent NHibernate or mapping files?
I, personally, like using mapping files, they are simple, uncomplicated and expose everything that NHibernate can do. Active Record is nice if you want to put the persistence definition right there along the class definition. Another major advantage of Active Record is that it is working hard to infer things for you. It makes working with it very easy.
Fluent NHibernate is mapping using C#. I don’t quite see the point there, especially since in some things FN decided to diverge from the NHibernate terminology, but I get why people love it. The part about it that I simply adore is the auto mapping support. That is a great way of getting things started.
But usually, even if I am using Fluent NHibernate or Active Record, I am mostly using them as scaffolding. At some point, I’ll ask them to generate the HBM for me and start working with them.
That is me, however, your mileage might vary.
Comments
Yeah I tried Fluent NH and eventually migrated away from it. I like the idea of fluent interfaces but most implementations I see these days abuse the concept badly.
I've spent a fair amount of time with AR, and it's nice. Loved it when I first tried it, but have since decided I don't like the persistance info in my models. I'm also no NH wizard so whipping out the mappings files isn't as intuitive for me as it probably is for Oren or Tuna, etc.
I've been using FluentNH with FluentMigrator, and I find it productive. It doesn't offend my sense of coding style, so it works for me. If it came down to needing really high performance, I'd probably just use NH or drop ORM all together.
For me, the appeal of FNH, besides that it's NotXML, are the conventions. Being able to specify in a single place a custom user type for a given .NET type, naming conventions, or things like common information in layer supertypes is an immense benefit, to the point where I'd never go back to HBMs.
If all you're doing is translating HBMs to code, it won't provide much more benefit than moving away from XML. But I see FNH opening new doors, with more opportunities in reducing or eliminating a lot of mapping duplication.
Yes, Fluent NH rocks!
once you enable the auto complete for the HBM files in Visual Studio, it makes it easier to remember the syntax. I started off with the HBM format so I never got what the issue or learning curve issue was. I'm not saying that I didn't have to learn at some point but those things come with time and sure I got frustrated and still do at times when I get an ambiguous mapping error (tho NHibernate errors have gotten more descriptive.)
I do get though for some people how Active Record or Fluent is easier to learn with and I fully support that because they're using ORM still and the best damn ORM for .Net :-)
I use Fluent NH because it supports automatic property refactoring because of the Lambda's it uses to specify the mappings. I use a similar solution for the (criteria) queries too.
Well, what about NHibernate.Mapping.Attributes? :)
It stays very close to HBM while still being good for prototyping (and all other advantages of writing the mapping using C# instead of XML).
I agree that FNH is great for refactorings.
For me it was key feature for choose it.
secondary, with hbm's i have a problem:
if hmb's included in assembly as Embeded Resource and I was changes something in hbm - I need recompile solution, VS is not detect this change as significant and not recompile project with hbm's by
Ctrl-Shift-B
Here is something that FNH gives that mapping files cant: it allows inheritance of mapping files... so if you have EntityBase that DomainClass inherit from, you can create an EntityBaseMap class that maps the properties that DomainClassMap inherit from and then it doesn't have to map the base properties. it's DRY.. ha ha ha..
Fluent NHibernate is great for working with drafting the mappings.
I provides strong typed property name which is really nice with intellisense. It is much easier and less cryptic to work with than the mapping files. Importing namespaces and use the class with Fluent NHibernate is much much easier than type the class name with namepsace and assembly name in xml.
I use Fluent NHibernate in a test project which will then generate the mapping files, which will be used by the application. This way, my application doesn't really need .NET 3.5, and there's no need for an additional dll to deploy with the application.
I like mapping files myself. They can be a bit intimidating when you look at the final product, but once you're familiar with the common structures and such I find they're understandable.
I like to work very incrementally so I build HBMs incrementally as I implement what's required. If you plan out an object model, go build all the classes, then try and write the HBMs afterwards to reflect or generate a data schema, it can be a bit of hurt.
Then again I'm a bit old fashioned. I don't like gen'd code, and I don't like gen'd schemas. So wiring as I go suits me just fine.
Whilst I think fluent designs can be a little ott these days I like the idea of code based mapping.. I think it should be a supported method because it has its own strengths away from xml mapping or attributes.
Over attributes it better allows allows persistence ignorance by having a 'stood off' data model like xml mapping files does, but over xml mapping files it has the benefits of compile time checking.
This seems to take the benefits from both attributed or xml mapping, but of course its weakness is the mapping needs to be compiled, where as xml mapping can be edited in the event the database schema changes slightly, but of course large schema changes would require your data models to change anyway so the benefits of the xml mapping seem less useful in that respect.
I started to use Fluen NHibernate ( using the NHibernate.Mapping.Attributes)
and it was very easy to start with it...(after a few setbacks) but than when i tried to create more complex classes with dictionaries and hastables as members - i found it very hard to map them into the DB.
for instance i created two classes with a member of type generic dictionary - when i added instances to that dictionary - those instances hasn't been added to a different table...
so i need to save both instances ( first the instance and then the dictionary) - and i don't want to do that....
anyone know what i am talking about?
Comment preview