I am in process of evaluating ORM first time. Please suggest which one i should choose for my next project.
I wrote couple of sample code with EF 4.1 code first. Before start same exercise with Nhibernate, I want to know if somebody have already experience with both in production application.
My evaluating criteria
Speed of database access
Learning curve (because I am new to ORM)
Community support
Tutorial/Books availability
Anything else which I should consider (Because I am noob to ORM)
I wish if people who have experience with both the ORM in production level app answer my question.
Thanks in advance!!!
I am aware that this question may be a little bit dangerous to ask ;)
Having used EF 4.1 and Castle ActiveRecord (based off NHibernate), I would rate them as follows:
Speed of DB access - NHibernate for anything remotely complex, otherwise about the same. The problem with EF is that it creates such convoluted SQL that it's difficult to know how to optimise it or if it's even possible to do so.
Learning curve - I personally found EF easier to get started with, but others may feel differently, and both certainly have a learning curve.
Community support - Depends on what you mean by 'support'. You'll find lots of info on the web (and this site) for both. NHibernate is open source, while EF is controlled by MS.
Tutorials/Books - I believe there are more 'official' resources available for EF at this time, but searching on forums will likely get you what you can't find in books.
Anthing else - Realize that the purpose of ORM's is to simplify the data access layer for the developer. However, both of these ORM's (and pretty much every other heavyweight ORM) expect you to use certain coding patterns for this simplification to be realized. While coding pattern enforcement isn't a Bad Thing (some would argue that it's a must), it's something you certainly need to prepare for before choosing one.
If you are a noob to ORM and only need the basic features you may find the Entity Framework and Nhibernate are over kill and should be looking at a light weight one like Massive:
https://github.com/robconery/massive
That said there are two main issues you face with EF vs NH
EF is all that microsoft support and so all their tooling by default uses EF. Making beginner code easier with EF.
NHibernate is more mature and has a greater feature set (if you need it) also has a good development community and lots of blog info about it.
I would choose Massive if you want simple / fast but unsupported, EF if you want easy and MS support but limited in some ways, or NHibernate if you have the time to learn a proper ORM.
Hope this helps.
Well im my personal experience Nhibernate have been the right choice, in complex situation have given me better time results, and it was a lot easier to learn.
I learned it first and then tried the Entity Framework and I found it easier to learn nhibernate Even though in that moment i didn't knew anything about ORM.
Community support and Tutorials and books I can say they are both good and have a lot of material to learn from.
Now I can use them both but still likes Nhibernate a lot more.
Related
I hear from everywhere that NHibernate 3 learning curve is very huge. It is considered huge from which perspectives ? Do you think that the learning needed depend on the scenario it is used ?
Example: If i just want some application that act on 3 entities and only looking for basic crud. Is it necessary to understand the whole concept underlying NH ?
Would like to know users experiences with some explanation over your answer to this.
Edit: Do you recommend of using NH over Entity Framework 4 ? (if you tried both)
Thanks.
There is a learning curve for any ORM. Once you've learned one ORM, learning a second ORM goes much faster. In most cases, it doesn't matter (learning speed wise) which ORM you learn first.
Currently, I think you can probably get going faster initially with EF4 than NHibernate, but over the long term I think NHibernate is a superior choice. Those are the main two ORMs worth spending time on at the moment.
Once you understand ORMs, your development speed will be much faster in regards to database access. There are other benefits to ORMs as well, so it's definitely worth taking that learning curve on.
NHibernate indeed does have a leaening curve, but it all depends what your background is...
Is the concept of ORM's familiar to you at all ? Do you have experience working with Entity Framework 4 ?
In order to build a simple application with 3 entities/tables and simple CRUD operations, you don't need to understand the core of NH, but problems will start to come up when you think of expanding the program you are building or the moment you run into bugs or features that you will only find out along the way...
I really suggest using NH, and learning it is always easier on programs with a small db like the one you're probably going to be working on.
I would also suggest diving straight into Fluent NHibernate. It's a way of mapping the entities without using XML at all.
Start out by reading the introduction and the 'first project' page at the Fluent Nhibernate homepage.
You can read alot more about NHibernate and Fluent NHibernate at ayende's blog.
You can learn the NH basics in a single day. And believe me, it will pay off.
I learned EF after NH and can say that if you are going to use automappings, POCO objects etc then learning will be just the same.
NHibernate has NOT a "steep, large, horrendous learning curve".
I learnt NHibernate just reading the (excellent, BTW) manual. It was v1.2 and, believe me, it is much better now than then.
New year - new startup :)
We are chosing ORM. I personally worked with LLBLGEN last years.
I've looked through EF4 today and have found that its functionality is close to llblgen.
(filtering, sorting, grouping, working with stored procedures and functions, working with graphs of objects (prefetch path), lazyLoad).
I know that llblgen doesn't support POCO, that means that it is required to write additional (or more complex) code to decouple it from Domain.
I don't think that llblgen license is con as llblgen is real successful alternative to Microsoft's orms and it is cool that we have such alternatives.
I didn't find any concrete comparison of these orms in stackoverflow.
Just something like "If it is not critical to pay maney then use llblgen" :).
So I just want to list pros and cons of LLBLGEN and EF4. (ORMs functionality only without designers features)
I have used LLB on several projects over the last few years and I am just finishing off my first EF4 project.
Both are perfectly fine for simple 1-1 mappings between objects-tables. Doubtless other people would disagree, but for projects where I use codegen I try and keep that the case as far as possible.
I'm no EF4 expert, so theres probably things it can do that I've not discovered yet but I feel that LLB is a more mature product and the support is absolutely fantastic.
Surprisingly enough getting help on EF4 is nowhere near as easy and googling for the answers can be difficult because you end up with loads of unrelated C# hits. The LLB forums tend to give you detailed answers to your code snippets very quickly - normally within hours.
But MS being the huge beast that it is I had to give EF4 a try on a project, and things have worked out fine. But personally I still prefer LLB.
Pro for LLBLGen - support. Very responsive support forum with issues typically fixed in a day or 2 (or sometimes hours)
Try getting that level of support for EF (or any other ORM come to that !)
Ok guys. Let me summarize my question after studying EF4.
It is possible to use EF4 with POCO objects that is good if you are working with Domain model. LLB doesn't support POCO.
LLB entities has state even without dataContext (Adapter scenario). It means that you can get entity in one context and save it in another and second context will know that entity is not new. EF4 will treat it as new Entity and it is require to write additional code to mark it as updated.
LLB has SelfServicing scenario that is good for small applications as entities have self saving and lazy load functionality.
As mentioned above, LLB has great support. It seems the rule is to answer during 8h in workdays and 24h in weekends.
LLBLGen is so mature that it generates about six times as much code as necessary. Keep in mind that its first of many confusing and overcomplicated APIs had been designed long before the introduction of generics and LINQ and it shows. Starting a new project using LLBLGen is only understandable if you have already invested years in learning it. In all other cases do yourself a favor and forget it ever existed!
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 am starting to delve into the realm of ORMs, particularly NHibernate in developing .NET data-aware applications. I must say that the learning curve is pretty steep and that a lot of things should be noted. Apparently, it actually changes the way you do data-aware applications, manner of coding, development and just about everything.
Anyway, I want to ask if you do set some parameters when deciding to USE or NOT TO USE ORMs in your applications? How do you decide then the approach that one needs to make it valuable to your organization?
The organization which I work for now apparently has made a lot of SQL and Data Access thing running through back end and I must say that these class/methods/procedures have successfully performed their tasks of providing the data which is needed and when it is needed. I think it would be a tremendous effort just to map some of this into ORM and derive the same business value that the company has for the last few years.
Nevertheless, I know that ORM paves the way for applications to talk with database servers, if properly implemented. I must admit that I am at a learning stage and that I would possibly need all the help, resources and the guidance to make this transition. I was also thinking of buying the book from Manning but I feel that with so much changes to NHibernate, the book may be a bit outdated. Perhaps waiting for the Packt book on NHibernate (release on May 2010??) would help me better get up and running.
Kindly share your thoughts. By the way, if you could also point me in a small sample web app which uses NHibernate + Visual Web Developer 2008 Express and SQL Server, that would be highly appreciated.
Thanks.
For me, the short of it is the following:
If you don't use an established ORM, and you develop correctly (meaning you refactor out duplication and look to simplify where you can), you'll wind up building your own ORM through the evolution of your data access layer.
The question then becomes:
"Do I want my developers spending time learning the idiosyncrasies of my home-grown ORM or learning those of a well-documented and well-tested ORM?"
Furthermore:
"If I'm hiring a new developer, wouldn't it be nicer to bring in a developer that knows the established ORM tool we're using rather than having to train someone up on this thing I built?"
I use NHibernate, particularly Fluent - and it's great; if given the choice, I wouldn't develop on an RDBMS any other way.
To be successful with an ORM you must make sure to normalize correctly, and use the database for it's designed purpose, storing data.
I don't use an orm when:
I don't use a relation database (Relational databases are not the best choice of database for every application)
The database is has a very small amount of tables. (I might need less code without an orm)
I use a very simple database that can map to code with simple naming
conventions. (Mapping to dumb DTO classes and all queries like select * from tablename where id=#id)
Learning a good orm is worth the time and effort, it will save you writing a lot of code when you use relational databases a lot.
You can find example apps/tutorials/video's about NHibernate on with stackoverflow search. There is another book in progress by manning, maybe it's possible to read it with the early access program.
This is probably a long shot.
In the .NET world, has anyone found an ORM (Commercial or Open) that has the flexibility of NHibernate to support domain driven design with good Linq support? Linq to sql is dead, Entity Framework doesnt yet support POCO's, lazy load or object first development very well, and none of the old stand bys such as LLBLGen seem to either.
Anyone find anything new and exciting in the ORM market?
Thanks!
See ORMBattle.NET - it won't exactly answer your question (btw, I hardly admit this is possible), but there is some info on quality of LINQ support.
Note (or disclaimer): I'm one of persons related to creation of ORMBattle.NET, as well as one of DataObjects.Net authors.
Which version of the .NET Framework are you talking about? 3.5? 4.0?
There are quite a few ORMs out there and some of the commercial ones may in fact meet your needs (or be working on new releases that meet your needs). Competing against both NHibernate and Entity Framework from a commercial perspective is pretty daunting. Microsoft made it much harder than necessary to write a Linq provider, which is why so few ORMs have one. Writing a domain driven design oriented ORM that supports multiple database vendors is also a pretty steep hill to climb.
NHibernate certainly has all the momentum right now, but that doesn't mean it's invincible. It's hard to compete with free & open source software that has a multi-year head start, even for a company with the financial resources of Microsoft.
I think you may just need to be patient. NHibernate's Linq provider is improving and the other ORM vendors are working hard on improving their offerings as well. Things could change significantly in the next two years or so.
No, I don't know of any. Because NHibernate is popular and very good at what it does, and EF is likely to pick up most of the remainder (particularly devs that don't want to stray from Microsoft-supplied frameworks), the barrier to entry for a new player is very high. Another ORM would need to add something significant over and above what NHibernate currently offers in order to get any reasonable level of interest.
If there was an open source project that wanted to deliver better Linq support in an ORM, in my opinion it would have greater success contributing to NHibernate Linq rather than attempting to build its own framework from scratch.
I wouldn't call it a "NHibernate killer", but SubSonic works well. It's simple to use, allows you to choose between using the Active Record pattern and the Repository pattern. It supports POCOs, lets you use object-first development and setting up lazy-loading is easy enough.
CQRS could be considered an NHibernate killer. The basic premise is that your domain objects are not used to support your read model and application queries. As such, you can start using something more like a document store to hold your aggregate or even use event sourcing. To update your read model, you have it listen to the events published by your aggregate so that it can update itself accordingly. Using this architectural style we have been able to eliminate the our reliance upon NHibernate. Now if we decide to use an RDBMS, it's because of the strengths of the database rather than as the default choice.