Now that Oracle supports EF officially (at least in Beta), EF looks like a reasonable choice to work with Oracle database. In the other hand, NHibernate seems very suited for the same job.
Does anyone has experience with both? Any recommendation for someone who wants to get started?
Which one seem to make most sense on the long run?
EF is still a new born in regards of object persistance. It uses an underlying object inheritance which some times could make you lose your inheritance possibility while designing. This could have been fixed with the new version of EF, and still, it lacks the flexibility of NHibernate.
NHibernate is a port to .NET of Hibernate in JAVA. It is likely about the same maturity now, if I remember correctly from version 3.0 of NHibernate. It uses either Attribute mapping, XML mapping or you may also use Fluent NHibernate or ConfORM, which allow you to map your objects in an object-oriented and optionally convention-based manner.
Though EF4 seems to deliver more performance in some ways, my preference resides still with using NHibernate, as it has proved better flexibility with foreign database engines other than SQL Server, IMHO.
Please, see for yourself:
NHibernate vs. Entity Framework 4.0 (Ayende);
Entity Framework 4 vs NHibernate (SO);
EF4 compared to NHibernate;
Performance comparison of nHibernate and Entity Framework.
.net ORM Comparison (SO)
Related
I am coming from an Entity Framework and LLBL background for my ORM tools.
I have been asked to build a new system based on NHibernate. I have never done so, so I am coming at it with fresh eyes.
What is the difference between mapping with Fluent NHibernate and "Mapping By Code" in NHibernate? Is there a preference?
Fluent NH
Fluent NHibernate offers an alternative to NHibernate's standard XML
mapping files. Rather than writing XML documents, you write mappings
in strongly typed C# code. This allows for easy refactoring, improved
readability and more concise code.
vs.
NH's new mapping by code
It is an XML-less mapping solution being an integral part of
NHibernate since 3.2, based on ConfORM library. Its API tries to
conform to XML naming and structure. There's a strong convention in
how the mapping methods are built. Its names are almost always equal
to XML elements names.
Some of it is preference, some of it is existing codebase. There was a time when NHibernate did not have any built in non-XML mapping options. There were a few solutions out there to fix this - e.g. confORM, Fluent NHibernate, and others I'm probably not aware of.
As of 3.2 I believe (perhaps 3.0) NHibernate now has "Mapping by Code". The advantage to this over Fluent NHibernate is that it doesn't require an additional library, and it is supported by the same team as NHibernate. On the other hand, Fluent NHibernate is a bit more mature (From what I've heard) and can support a broader set of mapping functions.
I also mentioned "existing codebase". Obviously, if you have a project that is already mapped with Fluent NHibernate, it would be best to continue on with it. If you're starting fresh, perhaps it is worth a try to use the built-in "Mapping By Code"
I know this post is old but, for anyone else interested on this matter, I would strongly recommend you to read this blog. It made it pretty clear to me and it even also gives you comparisons between the two approaches.
http://notherdev.blogspot.de/2012/01/nhibernates-mapping-by-code-first.html
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/
I would basically like to know things such as:
Advantages/disadvantages between the two?
Similarities/differences between the two frameworks?
How are they similar/different architecturally?
How much boilerplate code is needed to use each?
Can the Entity Framework be used efficiently outside of Visual Studio compared to NHibernate? Is the Entity Framework more efficient than NHibernate when used with Visual Studio?
Note: This question refers to the Entity Framework 2 (currently still in development).
Disclaimer: This post is based on my current knowledge of what the next version of Entity Framework will be like. That might be inaccurate or it might change until the next version is actually relased.
General Approach:
The main approach of Entity Framework (EF) is using their graphical designer tool to create an Entity Data Model and to generate domain classes as well as mapping from that model. There is support for other approaches as well, but that way of working will probably always be the main one.
NHibernate (NH) is a text based tool which requires the user to write all the domain classes and mapping manually, if you don't turn to third party software for code generation, such as MyGeneration of CodeSmith, or additional convention over configuration support, such as Fluent NHibernate.
Code Generation:
Code generation is a major part of standard EF usage, either by using their graphical designer tool or by using their command line tools. The availability of both GUI and command line tools is a plus since makes EF easy to get started with as well as allowing for more advanced usage that can be automated, for example in a build process.
Code generation is not supported by NHibernate, except for the schema generation stuff if you want to count that as code gen. You can get code generation if you turn to third party software though.
Database Schema Generation:
EF will add support for model first development, by allowing the user to generate a schema from an Entity Data Model. NHibernate has had schema generation support for a long time. The difference here is how you create your "model", as mentioned earlier.
LINQ:
EF will have improved their whacky LINQ implementation from v1 and NH have now reached version 1.0 of LINQ to NH, so there should not be any major differences between the two in that regard.
POCO:
EF will add better support for the Domain Driven Design approach and the use of domain classes that are separated from the data access layer. However, since POCO is not the main use case of EF I can't really see how their POCO support could ever reach the level of NHibernate. The POCO support in EF is still young, and to me it feels more like that it is a bonus if you are a POCO/DDD supporter and you find yourself working on EF for some reason.
The entire NHibernate framework is build for POCO development, by DDD people, and they have reached version 2.1 as well as taking advantage of all the work put into Hibernate on the Java side. NHibernate will probably remain the no 1 choice for the DDD/POCO/ALT.NET crowd for quite some time.
Lazy Loading:
The next version of EF will include support for automatic lazy loading. Automatic lazy loading has been an important part of NHibernate for a long time.
Learning Curve:
Both frameworks are complex and powerful, and hence take a long time to master. But EF is quite beginner friendly since it is integrated into Visual Studio, with its graphical designer tool, and since it can generate a lot of stuff for you without you having to know just about anything about the framework. However, if you want to dig deeper into EF and really learn the framework, you should be prepared to spend quite a lot of time using it.
NHibernate has a notorious learning curve, but some recent improvements have reduced it a bit. Now that LINQ to NH is at v1.0 the query syntax will be easier to understand for developers new to NH, and the Fluent NHibernate project is improving the mapping experience, and even working on automatic mapping, which is getting better and better all the time.
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
Please if you have used NHibernate and Entity Frameworks, please contrast your experiences.
We were early adopters of LINQ to SQL, but only on a limited basis while waiting for the Entity Framework. We have only started working with EF, but my largest complaint is still the same one that I had with LINQ to SQL, being that my domain model is still married to either the data source or the framework, meaning my POCOs are not really as independent as they should be.
Of course, on the Entity Framework Design blog, they have recognized that persistence ignorance is a very popular requested feature (and will be in the next release), and there is at least one example of how to achieve persistence ignorance while using true POCOs here.
We also evaluated NHibernate. It is very solid and easy to use. Realistically, with all other things being equal, NHibernate is better established but I have a personal preference to stick with the Microsoft implementations unless I have a legitimate reason not to - if for no other reason than the quality level of support I can get.
You might also consider looking at Castle ActiveRecord, which is a layer on top of NHibernate. It makes the whole ORM thing sparkle, in my opinion.