Question says it all. Working with an old codebase that is using NHibernate 1.2. What do I stand to gain, and what will I lose, or experience in pain, as part of this upgrade? Is the total effort worth the benefit, and if so, what are those benefits? And while I'm at it, would it make sense to just move to Fluent NHibernate?
This really depends on what nhibernate functions you are using. Take the release nodes and see if anything is in there you are using. Most functions are still working the same in 3.2. You have to do some upgrades in your mapping files.
I would do one change at the time. So get it working without Fluent, and decide if it is worth doing going to fluent. You should also have a look a QueryOver and the usage of linq.
One of the most interesting new features in NH 3.2 is that you can now map with code, instead of with HBL files. This is the same feature that FNH has had for years, but integrated into the main NH project.
I have not used this myself in NH (I'm a big fan of FNH Automapping), but my reading indicates that many FNH users consider this much less mature than the FNH equivalent.
One area where FNH is still miles ahead of NH is the aforementioned Automapping. NH just does not do that yet (though there are some misleading blog posts which imply that it does).
Probably not of much value for your current project (you've already gone through the pain of setting up your HBL files), but could be very valuable for new projects. We use it in our project, and it allows us to almost change our object model at will, and let Automapping rebuild the database for us.
Lastly, as I write this there is no official release for FNH with NH 3.2. I've been experimenting with the latest FNH builds (1.3), and it's "not quite there yet". But it probably will be soon.
Nhibernate 3.2 has a mostly functional Linq provider, which is nice if you like Linq.
Related
We want to upgrade a rather large and old project from Nhiberate v2.0 to v4.1 to increase the performance further. Does anybody have any useful tips, howto's or best practices? Another option would be to switch to the Entity Framework if that is easier. Any guesses how many days the upgrade would take?
As for the upgrade itself, it should work out of the box, and, yes, you should upgrade it because there are lots of improvements and new features.
As for switching to Entity Framework, lots of things are so different. I suspect that you were not using LINQ with NHibernate 2.0; in Entity Framework, you need to use LINQ. Plus, the mappings are done in a totally different way, using attributes and code in Entity Framework.
I have one project using NHibernate 1.2. I know it's old, but I've used it since I'm working off NHibernate in Action, which targets that same version.
I've been thinking I should update my understanding of the tool, as well as the tool itself. But I wonder what the differences are between versions. I know 2.1 has been current for some time, and that 3.0 is in the works.
What benefits or features are gained, lost, or changed when moving to NHibernate 2.1 or 3.0?
Off the top of my head and mixing 2.X and 3.0 features... LINQ support, EventListeners (more powerful Interceptors), System.Transaction support, generics support, multiquery, future queries, SchemaUpdate (rather than just SchemaExport), much better HQL parser, ... Plus numerous bug fixes. A lot has been going on in the NHibernate world since NH 1.2...
With the 3.0.0 release, NHibernate
includes support for LINQ, along with
additional features such as:
Along with a long list of bug fixes
and improvements, it has several new
features including
A new strongly
typed criteria API called QueryOver
Lazy loading of columns
Alias delimiting in generated SQL
Support for DetachedCriteria within
IStatelessSession.
Improved support for LINQ, overcoming the HQL limitations of the previous provider.
Breaking change:
Upgrading users should be aware that
one of the fixes means that null
values in dictionaries are no longer
silently ignored, which has the
potential to break existing
application code.
James Kovacs summarized it pretty well, but for a complete list of changes check https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk/nhibernate/releasenotes.txt
It contains every single bug/improvement/new feature for all NH releases.
You get Linq support!
I started on 2.x+ so I can't say much...but I'll for sure upgrade to 3.0 once it's out of beta. Mainly because QueryOver looks like ICriteria on type safe steriods!
v3: Removal of the dependency on log4Net (which is often a love-it or hate-it thing)
is anyone building the truck NHibernate and FluentNhibernate together? How's it working? are you using it for production systems?
How is the Linq support?
Is it nearly ready for release?
Is there a nice and concise way to keep up to date with what is going on in the world of NHibernate? (ie, without having to read lots of blogs, and mailing lists )
You can find trunk FNH builds here: http://hornget.net/packages/orm/fluentnhibernate/fluentnhibernate-trunk (I haven't tried it as I don't use Fluent)
NHibernate 3.0 is pretty stable and the new Linq provider is very good, with an excelent coverage of the possible Linq constructs and clever, non-intrusive support of NHibernate specific concerns (caching, fetching)
I'd use it in production without much concern; being in a "pre-alpha" state only reflects the seriousness of the project team, as the current state is more similar to that of a Visual Studio RC than a CTP or Beta.
Update (2010-12-05): NHibernate 3 was released yesterday.
Directly on FNH site, under the download section, you can find the "Latest Master Build"
http://fluentnhibernate.org/downloads
If it may help
I am going to try using NHibernate, the reason I stayed away from NHibernate so far was the xml-mapping part. Now that (I found out) there is fluent nhibernate, looks like we don't need to do xml mapping.
But I am wondering if starting with some xml mapping, would be more helpful in learning and getting comfortable with NHibernate, or should I start using it with fluent for nhibernate?
cheers,
hazim
I had similar concerns when I started with nHibernate, but having taken the road of learning the mappings and then learning Fluent, I have to say I wish I had just started with Fluent.
My reasoning is that there was enough to digest just learning nHibernate and Fluent helps make nHibernate more simple. Having said that I agree with David M, you'll need to understand the mappings at some point.
This series was really useful when I was learning nHibernate.
HTH
I would actually recommend attacking NHib from a totally Fluent perspective right now - FNH has matured just enough to not drive you nuts with inconsistencies, there are a lot of decent learning aids out there (try and look at anything posted since Sep 2009 on at first), as well as a decently active user group.
I found this amazingly good and very recent video tutorial Vacation of Fluent NHibernate, conceptually based on the Summer of NHib series everyone else has here. Unfortunately the author just got a new job and hasn't yet completed the series, but I will be shocked if you don't find it incredibly approachable and useful as a learning tool all the same.
You also can fairly easily learn to generate the HBM maps, and reading them is way more useful IMO, and certainly less painful, than writing them at first.
Lastly, give yourself a break and don't expect to master any of this by the end of the week! If you spend some time with FNH first, you will know which areas of NHib you want to dig into eventually and feel less overwhelmed by it when you do.
Cheers,
Berryl
Suggest you get started with a simple database schema using Fluent's auto mapping, so you can get used to using NHibernate Sessions and SessionFactories properly. Then you can branch out. But at some point you will need to fall back on XML mapping, so it's worth looking at eventually.
For understanding what is going I'd recommend starting with XML Mapping files. When learning NHibernate I found hand building configuration files to be useful. That said after I was comfortable using fluent and the occasional mapping file builder has been great.
For learning NHibernate though it's targeted at a previous version the Summer of NHibernate is incredibly useful.
Start with the XML mappings. Fluent is getting closer to being feature complete, but the terminology it uses still diverges from the terminology within the XML mappings (which is what is used by most NHibernate tutorials / documentation). Once you've done a mapping or two, it really isn't that hard especially with intellisense support from the schema files.
Fluent NHibernate is great, but for a beginner I think it might lead to some confusion as you cross reference your mappings with online research.
We've been using our own DAL for our projects in our company and for the passed 2 projects this has causing us problems. Because of this I want to study SubSonic and/or NHibernate. Is it better to study SubSonic first or NHibernate? What are the advantages/disadvantages? From what I have read from related questions here NHibernate is more complex compared to SubSonic so I want to start with the latter.
SubSonic is significantly easier than NHibernate, you can start working with it almost immediately (few screencasts and you're done). In NHibernate you need some more work to start up – XML config, Session handling and such stuff. So if you are new to ORM, learn SubSonic first, and then delve into NHibernate. Personally I think for small projects you can even happily end up with SubSonic :)
SubSonic is an Active Record ORM. If that is what you are looking for you should compare it with other active record ORM's such as Castle. Castle is built on top of nHibernate so your team can expand to full feature set if needed. AT this point your comparing apples to apples and it doesn't matter which one you start with.
If your not looking for an Active Record style ORM try starting with Fluid nHivernate to lower the learning curve a little.
I dont know a great deal about SubSonic but I recently took on the task of tooling up with NHibernate and found this book (probably the only one out there really) very useful
NHibernate is definately more complex, but with that complexity comes greater flexibility. Subsonic is great, but you should also be aware that it's very much an open source project and whilst it's currently stable, it doesn't have the active development community behind it that NHibernate does.
Another thing to be aware of is that subsonic is a sort of "code generator" where it will actually generate a bunch of stuff for you. NHibernate is an ORM in the very literal sense in that you map objects to your database. You can use code generators to generate the mappings for you, but it is a fundamentally different way of thinking about ORMs.
Personally, if you look at subsonic and find that it has everything you need, than I would look at that, or possibly even linq to sql, however if you find you're getting into more complex object problems, then maybe NHibernate is worth learning.
The answer depends on many different factors. If you learn nHibernate, you are opening yourself many doors of learning curves but they all pay off. Sub Sonic can get you up to speed but is based on code generation which means you have boundaries. With nHibernate, you define you own mapping. Infact with Fluent Interface nHibernate mapping, it's much more easier, simpler and faster to map the objects. There is a very active users group link text
Plus you have full flexibility of mapping. nHibernate could be a little hard to start with but it's totally worth learning. I myself have written 2 professional projects for my clients using nHibernate.