considering the latest version of Entity framework as against NHibernate, is there a reason why I should use NHibernate as opposed to the latest version of Entity framework?
Are there features of Nhibernate that is not covered by current version of Entity framework?
thanks
There are tons of posts about differences between NH and EF - do some yourselves research if you want to get complete answer.
Short version:
EF 4.1 brings only new way to use EF 4.0 - it means new simplified API called (DbContext) and code mapping. Both these new features are more limited than original EF 4.0.
EF 4.3 brings code-first migrations for incremental data model development.
EF 4.5 Beta / EF 5.0 Beta brings support for enums, spatial types, table valued functions, auto compiled queries + performance and API improvements.
There are a lot of NH's features which are still not possible in EF
More possibilities for complex mapping
Custom type mapping
Batch command execution
Future queries
2nd level cache
Extensibility and a lot of ready to use extensions
A lot of hooks where you can replace NH's default implementation with your own or add new logic
etc.
EF has better LINQ support and it is from MS - for many companies this is important decision point. You can check data user voice to see what features are currently requested from ADO.NET team for next releases.
Related
I'm still struggling to decide whether to use EF6 or core for my small business management system I'm going to create in VB net. I've already created an SQL database that has about 100 tables and the data won't be very intensive. I've read that core doesn't support model first but I've also read that it's possible to do code first that's based on an existing database. (didn't really understand that but I'll research it if I decide to go core).
A few months ago I was determined that I'd just stick to v6 which has been around forever, most popular, and probably has all the functionality I'd ever need for my small business and won't be going anywhere in the near future.
But now I see core.2 came out and I understand that since core was build from the ground up, MS has a special interest in developing it to be the best EF out there. I have a feeling that although v6 won't be going anywhere soon, that MS will be putting most of there effort into core with each new version and of course, you can always upgrade to newer versions but as I understood, will never be able to convert a project from v6 to core. So I feel like I'd regret starting with v6 and being stuck with it and missing out on the "core-train".
What do you think?
The EntityFrameworkCore is not mature now, we have met lots of issues. So you should wait for 3.0 if you want to use it in your projects.
I have a feeling that although v6 won't be going anywhere soon
I believe you are right here. Microsoft may add some fixes on EF6 but they will probably not do any heavy development here since they will put their effort on EF Core.
Disclaimer: I'm the owner of the project Entity Framework Classic
Entity Framework Classic is a supported version from the latest EF6 code base. It supports .NET Framework and .NET Core and overcomes some EF limitations by adding tons of must-haves built-in features.
There is a Community Version (Free) and Enterprise Version (Paid).
As being the owner of several EF library such as Entity Framework Extensions, Entity Framework Plus, EF Dynamic Filter, EF Effort, EF Graph Diff, and more. You can expect this library to have some ongoing development.
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)
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 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.