Basic clarifications about NHibernate

Question

Given that I'm very good with SQL and c#,

1. Should I learn another layer on top like NHibernate ?
2. Is NHibernate just a library (that stores in a Database)? Or it's a service?
3. Should I use NHibernate or ADO.NET Entity Framework?
4. If you think I should learn/use an ORM, give me your top reason.

Answer 1

You should use an ORM as long as you need to convert database data to and from business objects, since it will save you a lot of work and will allow you to focus on your application logic.

NHibernate is a .NET library that does just that, mapping .NET objects to database tables according to how you configure it. In this sense it is the same as the Entity Framework, only that EF is already embedded in the .NET framework and NHibernate is a separate assembly that you must reference in your project.

Last but not least, if you use SQL Server you should add LINQ to SQL to the list of possible ORM candidates, it is simpler that EF and for many scenarios it is more than appropriate.

Answer 2

1. Probably, but it depends on what kind of applications you normally write.
2. NHibernate is primarily a DLL, but there is more to it than that.
3. NHibernate (Read this for more details: http://stackoverflow.com/questions/1377236/nhibernate-entity-framework-active-records-or-linq2sql/)
4. My top reason would be so you can use Linq. Right now, you pretty much need an ORM to use Linq.

Answer 3

1. It depends on your applications.
2. NHibernate is a library. So it's a DLL.
3. Depends on what you want. NHibernate is based on Hibernate which is battle tested.
4. It doesn't matter how good anyone is with SQL or C#. There is a fundamental gap with the tools when dealing with SQL and C#. Aside from all the other productivity boosts that I've had when I learned to Stop Worrying and Just Use an ORM, I found only having to deal with C# most of the time has helped greatly. I have far fewer impedance mismatches in my work now and I do believe that contributes to fewer bugs.
5. Less code you have to write is less code you have to maintain. ORMs allow you to worry less about certain details so you are free to concentrate on higher level tasks.

Answer 4

1. No, I tried Fluent NH and Castle Active Record and Spring Framework NH Extensions but they all obscure basic operations and make things less visible. Start using native NH, then add a layer after a year.
2. Yes, NH is a library, not a service. But the way you use it in your code makes it feel almost like a service (e.g. a data repository service)
3. I tried EF and found it nauseating so I would go with NH
4. For OLTP-like systems, ORM is the way of the future. Not using ORM for me is like not using unit-tests or programming in non-OOP language.

Answer 5

1. Unless it's a very small application, then the answer is 'yes'.
2. Library.
3. I hear people swear by the EF, but I'm very leery of it. I also don't like tying myself to all Microsoft technologies. NHibernate would be my suggestion.
4. First, you don't want to go through the time and headache of writing all the SQL and classes and such; it's just not worth it. Second, it allows for greater ability to switch from one RDBMS to another without having to change much code. Third, it'll give you more control in the future in terms of database abstraction and such.