Take the 2-minute tour ×

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?

share|improve this question
NHibernate is an option, as an ADO.NET Entity Framework (check it too). –  Viktor Jevdokimov Sep 29 '09 at 13:20
Search NHibernate.Mapping.Attributes -- no need to store database metadata in XML. –  Jon Seigel Sep 29 '09 at 13:30
You can also know "exactly what everything does and how everything works" while using NHibernate; the source code is readily available. There are also other great tools like NHProf to show you what's going on. –  Ryan Duffield Sep 29 '09 at 14:15
Thank you all for the response! I am going to look into NHibernate in combination with the Mapping Attributes. –  Ruud van Falier Sep 29 '09 at 14:35

13 Answers 13

up vote 24 down vote accepted

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.

share|improve this answer
In the words of Ayende Rahien... Stop stealing from your customers (by wasting time writing your own framework). –  Shane Courtrille Sep 29 '09 at 14:46
Also, standards are nice. The poor fella who has to maintain your code in 2 years from now, might not have a clue about how you did your DAL. If you were to use an ORM, he just have to read up on that ORM and he'll be miles ahead :) –  cwap Oct 4 '09 at 20:37

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
Beat me to it. @Ruud's problem screams out to be solved by Fluent NHibernate. Good call. –  Rap Sep 29 '09 at 14:56
Minor nitpick: EF v2 = EF v4 to coincide with the .NET 4.0 version number :) –  Ahmad Mageed Sep 29 '09 at 17:12

People tend to use frameworks that are already written because, well, they're already written (and tested).

But there IS merit to rolling your own. Only you and your colleagues can make assumptions about your domain. A generic framework like NHibernate cannot make many assumptions, because that wouldn't make it very universal.

When you roll your own, you can bake these assumptions into your framework, to make a more streamlined, natural API. That said, if you were starting over I would have suggested taking an existing framework and wrapping it to better suit your needs. But since you already have something and it works for you, I'm not sure that I would suggest swapping it out for something else.

share|improve this answer

It depends on what they mean by "foolish."

If by "foolish" they mean you shouldn't have written your persistence layer in the first place, they're probably right, but that's crying over spilled milk.

If by "foolish" they mean you should rewrite all your existing code to use another framework (like NHibernate) when it's already working with yours, they're probably wrong (although there's something to be said for # of bugs in NHibernate vs likely # of bugs in yours).

If by "foolish" they mean the entire team knows NHibernate cold, and it's already used in the rest of your code, so by using your framework you're making it harder on the team, they're absolutely right, and you should probably refactor the code in NHibernate as soon as possible, before any more code gets locked in to your framework.

If by "foolish" they mean no one there really knows NHibernate, they just like it, then... nobody wins. They're being fussy, you implemented a framework you didn't have to... let's call it a tie.

All of that said, everyone should write a persistence framework or three. Those probably shouldn't end up in anything that ships, but it's a good exercise. The only mistake you made was tying code the team had to maintain into your good exercise.

share|improve this answer

There are many good persistence tools out there that are well tested and have proven performance (NHibernate, Linq to entities, LLBL Gen Pro). If your needs are very different from the normal persistence frameworks that exist then I would roll my own. I would want to take advantage of the testing and optimizations of an existing tool if at all possible, however.

That being said, I might also roll my own if I wanted to have the experience of building my own ORM tool and was willing to live with the downsides (not as well tested or optimized as tools that have been around for years, speed to market).

share|improve this answer

Making your own solution, especially when it seems to work fine and be as simple as you say, is neither ignorant nor strange. There are lots of situations where it's better to do that than to add a dependency on a separate project like nHibernate.

That said, there are of course also a lot of situations where the complete opposite is true. :)

It really depends on your project and team. If you are developing an enterprise application that will eventually be supported by someone else, sticking to industry standards might be a good idea even if it means a bit more work up front.

share|improve this answer

All of the answers here are great, but I am really surprised that nobody has mentioned Castle ActiveRecord, it sounds very similar to what your framework does and really simplifies the interface to NHibernate. It's one of the patterns that made Ruby on Rails so popular after all!

Ayende Rahien (one of the principal NH developers) gave a GREAT presentation on ActiveRecord at Oredev a few years ago which I highly recommend: http://www.viddler.com/explore/oredev/videos/89

share|improve this answer

I think that it is a matter of balance of control. You say that you want control and you don't want mappings. If this control comes at the cost that there is an increased development and maintenance cost and that it takes longer to produce working code, then it is a problem.

I personally don't see a problem in rolling a framework as long as it simplifies a repetitive task and makes development more productive and code more stable due to less room for interpretation. We have rolled our own framework, that includes a persistence/data access implementation. Our reasons for doing it, though, were specific. In this case, it was to work within a DDD environment that was much closer to what Evans describes than what most off the shelf products were providing.

I think the difference is, though, that we understood that there was an upfront cost and that it would eventually balance itself out through savings in development time in the future. Of course, if you are writing code that you manually have to manage connections, map data, etc., you are probably going down the wrong path. At the very least, you could be using something like Enterprise Library to help you manage the tedium of connectivity and command construction. But, I also think, that if you have no reuse - nothing that is a "framework" type of implementation that you can abstract and apply to other projects, then you are creating a maintenance nightmare and time sink that you will be the sole owner of.

share|improve this answer

We were also using our own Data Access Layer and entity classes. We also had a code generator who used to generate all this classes for us. But now we are using Entity Framework and we are more then happy.

Simple advise : Start learning nHibernate or whatever you prefer and start using it in your next project.

share|improve this answer

Entity Spaces - http://www.entityspaces.net/Portal/Default.aspx

is also a good tool.

share|improve this answer

I ended up using Fluent NHibernate for the job. All my entity classes were generated with ActiveRecordGenerator (http://code.google.com/p/active-record-gen/)

share|improve this answer

Your Answer


