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.
Related
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.
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/
Let me say i know NOTHING about nhibernate except its for databases. I am doing a fairly small project, should i learn nhibernate?
I guess i have 4 questions
Is using a nhibernate overkill in a small project?
What should i NOT use nhibernate for?
if i have a large project should i use nhibernate if it has very complex tables? What about simple table schemes?
nhibernate is a very flexible system and can be used with simple databases or more complex ones. The real question comes down to what your project is rather then if its big or small and how much time you want to spend setting up a good design. If your site is just pulling a table out of database listing it on the webpage for viewing and editing. nhibernate is over kill, you simply have no need for the business objects it will create. On the other hand if business/domain objects are the center point of your project then you can benefit from use of nhibernate.
Why not start using nhibernate on a small project? This is a good way to learn it without the additional complication and stress of learning it on a large project.
It certainly doesn't hurt to learn nhibernate but it might be a bit of overkill for a small project. A small project is a great chance to learn nhibernate but if you are in a rush to get it done you're probably better off without it for now.
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.