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.
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.
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 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.
Are there any good alternative to NHibernate's xml mappings?
I have seen Fluent. All I look for is high maintainability.
UPDATE : I would like to know the performance issues related with using fluent because I guess it is going to create xml mappings from the class (which can be time consuming - my guess)
Thanks
Fluent, but then again I would say that.
There's a minor performance impact by using it, but it's got nothing to do with XML generation*. NHibernate has a start-up time of it's own, and fluent only adds a fraction onto that; it's not even worth thinking about unless you're throwing around thousands of mappings (and more specifically, assemblies).
* Fluent's performance impact is actually from calling Assembly.GetTypes() to find any mappings in your assemblies.
I have seen Fluent..
Then go for it!
Fluent is a great alternative. I use NHibernate with Fluent, and it has been working out very well. I find the Fluent Configuration being much more maintainable and nicer than default NHibernate configuration.
Check out the Fluent Wiki - great documentation and a good starting point.
Regarding your edit I can't give you any concrete answers, but I have never seen any performance issues using Fluent myself. I assume NHibernate alone would be slightly faster on startup, but once the mappings are made there should be no difference. Also note that the performance in writing the code will be better due to the simplicity Fluent offers ahead of NHibernate configuration.
I used Linq To XSD to generate a class library from the mapping file xsd definition which gives you statically typed mappings, which you can write helpers and conventions for. The nice thing about it is that the syntax looks very similar to a normal hbm.xml file, while I haven't had the time to learn how to do each mapping in Fluent.
Other options are ActiveRecord and NHibernate.Mapping.Attributes
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.