Is it foolish of me not to use NHibernate for my project?

Question

I am working on a .NET web application that uses an SQL Server database with approximatly 20 to 30 tables. Most tables will be included in the .NET solution as class. I have written my own data access layer to read the objects from, and write them to the database. The whole thing is consist of just a few classes and very few lines of code en uses generics and reflection to find out what SQL and parameters to use. Now, such thing could be done by using NHibernate (or similair framework) and some co-workers claim that is foolish of me not to use it. My main argument for not using it is that i want maximum control over my application, know exactly what everything does and how everything works, even if that costs me more development time. I also dont like the fact i have to map my database in XML files (my own solution lets me map it in the entity class files).

So, what i would like to hear from you is, is it really stupid to not use NHibernate in this situation? Am i really being ignorant or is it not such a strange idea to use my own solution?

Answer 1

I think these days there really isn't any reason to roll your own persistence framework since there are so many good choices out there. You don't have to use NHibernate (though it is a good choice) but I would seriously consider using something that is well tested and established in the industry as it will tend to perform better and have less bugs that something you write yourself.

Answer 2

It probably is foolish to write your own classes instead of using NHibernate, but it's less foolish to continue using your own classes, given that you've already written them. Maybe.

Answer 3

I won't call you foolish because I've done exactly the same thing in the past. Then I started using NHibernate and wondered why the hell I rolled my own. It's good, give it a go.

Answer 4

You have several possibilities that are probably better than you reinventing the wheel. Let me name two most likely choices:

1. Use Entity Framework for your DAL+DAO. This will make your classes (that you've already written) obsolete, since EF will create their own and you'll get up to date with latest language capabilities and technologies.

2. Use Fluent NHibernate so you don't have to work with XML mappings. This way you'll keep your business layer object classes you've written and avoid tedious NHibernation XML files. It's all C#.

Your way of thinking is good. You want control. That's fine. But using your own DAL is a bit foolish these days, because you are basically reinventing the wheel, plus you'll have not tested/buggy code that will take considerable time to develop+test+debug.

If I were you, I'd go with the #2 option, since I've done option #1 and I know I had to customize lots of things to make EF work as it should. EF will be ready with V2.