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)
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.
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.
I know this has been asked several times and I have read all the posts as well but they all are very old. And considering there have been advancements in versions and releases, I am hoping there might be fresh views.
We are building a new application on ASP.NET MVC and need to finalize on an ORM tool. We have never used ORM before and have pretty much boiled down to two - nHibernate & Entity Framework.
I really need some advice from someone who has used both these tools and can recommend based on experience. There are three points that I am focusing on to finalize -
Performance
Learning Curve
Overall Capability
Your advice will be highly appreciated.
Best Regards,
I would use Nhibernate. I would pickup Sharp Architecture as a great framework that wraps NHibernate, ASP.NET MVC and a bunch of other open-source tools into a coherent whole that will give you a solid architectural foundation.
Nhibernate is more mature than EF4. It is well supported by the community. As long as you are willing to get your hands dirty from time to time, you will like it. It's support for LINQ is currently a little weak but it is rapidly getting better. The learning curve is not bad, but things like session management can be a little confusing at first. One of the reasons I like Sharp Architecture is they have all the NHibernate stuff you will need in place and plenty of guidance on how to use it properly in an ASP.NET MVC project.
EF4 has the MS stamp of approval. It is pretty good now but still behind NHibernate. It is a perfectly good choice and you will find lots of docs from MS, MS support and eventually more developers that are familiar with the ins and outs. I should also mention that the Sharp Architecture folks are adding support for EF4 to their overall framework. They will still support NHibernate, but you will be able to use EF4 if you like.
I think it takes more time to learn NHibernate.
EF provides graphical designer, unfortunately NHibernate doesn't have a generic designer. BTW it's not a problem. If you design in domain-driven (DDD) manner, you will design your entities first and you don't care about database structure (as you used to), NHibernate will handle that for you.
EF 4 got closer to NHibernate. I wouldn't start working with EF 3.5, it lacks a lot of features.
If you think NHibernate is too complicated at first sight, you can start with frameworks built on top of NHibernate. ActiveRecords and Sharp Architect are good examples.
AFAIR EF 3.5 supported only SQL Server 2000. It couldn't handle the new data types from SQL Server 2005. I have no information on EF 4 but I suppose it support these improvements.
If you use NHibernate in real word applications, you have to build an infrastructure. E.g. I implemented the Unit of Work and Repository patterns to be able to write tests and create layers in my application. You have to expect the same using EF. Detaching and attaching entities in EF 3.5 was not an easy thing, I had to write tricky extension methods to mark fields dirty and so on. I hope they solved it in EF 4. There is no such problem with NHibernate.
You don't have to write HQL queries in NHibernate, you can use the LINQ provider. I think it's very important. :)
All in all NHibernate is a mature product with good community and commercial support. EF is young but strongly supported by Microsoft. Oh, and EF is a Microsoft-only thing while you can port your NHibernate knowledge to Java as well. It this counts for you.
I'm trying to look into this...
After building apps into both, NHibernate is definitely more powerful, but it's also quite clunky where EF is very clean. And after working with Rails/ActiveRecord, both are very feature rich in comparison, so either would definitely work!
I noticed that NHibernate keeps track of what it just ran, and if it just ran a statement, it doesn't exectute it again, so a properly designed app will run minimal database statements. I know that EF is not exactly slow either, but I'm not sure if it caches statements and results in the same way. For a large app, this could save some database resources!
So in short, NHibernate for functionality and configurability, and EF 4.0 for cleanliness and a quick easy learning curve. Also, one should expect EF in the next version or two should may catch up to or surpass NHibernate in functionality too, so it may make sense to have some familiarity with both.
just take a look at this
http://gregdoesit.com/2009/08/nhibernate-vs-entity-framework-a-performance-test/
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 need to collect some information about existing ORM solutions.
Please feel free to write about any programming language.
Can you tell about the best ORM framework you ever use and why is it better then others?
I used NHibernate and Entity Framework.
Current stable version of entity framework is very immature. It is too difficult, or impossible to perform common tasks. Testing your code is also difficult since you cannot really separate your entities from your data access classes. But it perfectly integrates with visual studio ide. Setting up is easy and updating all the models from database takes just a few seconds. Upcoming version of EF (4.0) will solve some of this problems.
NHibernate is quite powerful. It supports plain old clr objects, so you can work with simple entities. Configurations provide great control in great detail. Framework capabilities are satisfying and it has a large and active community and good documentation. Setting up and updating entities is a little difficult since you must use generators that looks up your database and generates entities and xml files. It may be tricky to find a generator or a template that exactly fits your needs. But once you set all things up, you will love it.
I found LINQ to SQL to be a pretty straight forward solution. The first time I used it, I'd say I had a basic ORM working within a few hours, and was creating LINQ queries with it.
Microsoft has an additional ORM (Entity Framework), which I've heard is more complex but may be useful for highly complex distributed applications with multiple data sources etc.
Overall I found LINQ to be an easy and fast to use ORM.
I have been looking at Telerik Open Access for last few months, in genernal this ORM has been a pain to work with, it was advertised as having extensive linq support but in reality many of the linq features you would normally expect dont work server side and are performed on the client. I also had problems using multiple conditions in a where clause, see my last question. Here are a few things that i found
No support for views
Unable to map more than one entity to the same table
Inheritance and Interface support requires you to make changes to you database schema
No visual designer like LINQ to SQL and Entity Framework
If you want to perform an insert any related entities must be fetched first
Rohan
LINQ2SQL was nice, EF makes sense, but is very complex and SQL Server oriented. NHibernate is special and Telerik OpenAccess (fully .NET / Visual Studio) got a broad set of functionality and professional support.
Since I know the product I can comment on Rohan's concerns:
Existing Views can be used and full Views support is coming up
Mapping more than one entity to the same table "works" for class hierarchies, limitation with reverse mapping exists
Inheritance and Interfacer support "do not require" changes to the the database schema, again limitation with reverse mapping exists though
Visual Designer will come, Forward and Reverse Mapping Wizards allow you already to do anything in an easy way
There is a workaround for the insert issue mentioned and it will be fixed generally
Check out the Telerik site to find happy customers and feel free to use the telerik forums and support resources for any question.
-Peter
Im new to OpenAccess ORM and we are using two products. Reporting and OpenAccess.
I think there are some features that people missed.
OpenAccess uses graphical designers while nHibernate still uses handwritten xml files
OpenAccess is not limited to SQl Server as EF4 and similiar frameworks
using it is easier and the forums are pretty helpful.
With ORM there are multiple possibilities, all depends what you want.
As a real ORM mapper I strongly recomment NHibernate and Fluent NH mappings. You need a lot of research to put together a nice architecture, but then nothing stands in your way. With minimal compromises you get real flexibility.
EF6x (core is not prod.-ready IMHO) is called an ORM, but what it generates is more closer to a DAL. There are some thing's you can't do effectively with EF6. Still, this is my favorite tool for a read-model, while I do combine it with NHibernate (where NH I use for a DDD/write model).
Now to performance - its always pro and cons. If you deep deeper into ORM architecture (see my article: avoid ORM bad habits) then you will find intuitively the ways to make it faster. Here's my another article on how to make EF6x 5x faster (at least for read situations): EF6.x 5x faster