What percent of your codebase is represented by Data Access code?

Question

An interesting question came up on twitter tonight and I tought I'd post it here.

Basically, I am wondering what you are using to persist data to your database and an estimation of the percent of your codebase that is data access code.

-- Edit --
Other interesting metrics (as noted in the comments) include the number of business classes and the overall size of your codebase.

I just looked at a project that I did a long time before discovering NHibernate. Quickly looking at some of the data access code showed about 10 lines of code for persistence/hydration for every persistable property in a class.

Answer 1

We use nHibernate most of the times, and it being generated by a tool, dunno if that counts, we still end up adding a lot of code to the nHibernate layer for each of the entities and yes; it does go on to be a large part of the code.

Also the DAL code increases as you add in more functionality and more entities in you app. So more or less i guess around 20%-30% of our codebase is composed of the DAL.

Answer 2

In one project we did, we used LLBLGenPro as our OR/M. But since we didn't want to litter our application with LLBL entities, we mapped those to our BO's before they hit the client. That mean mapping them back to LLBL entities before hitting the DB again. The DAL code ended up being a very big portion of our application. Not 50%, but sizable.

In a project I am working on now I started with db40 hoping to minimize the DAL footprint. And it was very small, but I ran into problems with db40 and had to abandon it. I switched to ADO.NET for a few days just to get something working and was amazed at how much freakin' ADO I had to write just to get a simple repository working. That was a headache, so I finally opted for NHibernate.

My DAL code with NHibernate (2.0) is probably 5% or less of my code base. That's including the XML mapping files. I mean, the DAL footprint is so small and such a pleasure to work with. I had problems with NHibernate 1.2 in the past in a distributed environment where I needed to work with detached objects, but NHibernate 2.0 seems to have solved that issue. I know it's the way I'm doing DAL from now on, until something better comes along.

Interestingly, my colleagues and I had a similar conversation a couple of months ago. But ours was focused not so much on how much code our DAL accounted for, but how much of our application was simply data querying/manipulation. We estimated that probably 90% of our application was just a matter of fetching the correct subset of data and allowing users to edit it.