views:

114

answers:

3

I have a lot of classes for data-access in one of my projects, but these classes are becoming extremely bulky because of the code that retrieves the data from the data readers.

My code generally looks like this:

// Execute the data reader
using (DbDataReader reader = command.ExecuteReader())
{
  while (reader.Read())
  {
     obj = this.FillDataReader(reader);
     objlist.Add(obj);
  }
}

internal SomeObject FillDataReader(IDataReader dr)
{
   SomeObject obj = new SomeObject ();


   if (!dr.IsDBNull(dr.GetOrdinal("objectID")))
   {
     obj.ID = dr.GetInt32(dr.GetOrdinal("objectID"));
   }

   return obj;
}

Some of the Fill methods easily hit 400+ lines, so is there a decent way to separate these out? Would partial classes be acceptable? In an ideal world, I would be using an ORM, but unfortunately I can't afford the time to learn how to use one.

+4  A: 

Certainly you could use partial classes to split away the code for the Fill methods. You could even look at using a template system to generate these partial class files.

That said, an ORM is a simpler solution and doesn't really take that long to work out if your needs are simple.

For basic needs where you don't need fine control LINQ to SQL works a treat, and contrary to what many thought it's getting updated as part of VS 2010 / .NET 4.

Another option is Entity Framework, also being updated as part of VS 2010 / .NET 4. It gives you a lot more control, but also can require a bit more learning.

How long does it take you to create these 400+ line long Fill methods? Are you sure you couldn't use that time to learn an ORM? No programmer should feel forced to constantly write cookie-cutter code (e.g. ADO.NET Fill methods), it can quickly take the joy out of programming!

Timothy Walters
Agreed -- sure, some ORMs do take a long time to learn, but if you can't learn LINQ to SQL in the time it takes to write a 400-line method, all I can say is... uh, you must be jolly quick at writing 400-line methods! **grin**
itowlson
I would not agree that LinqToSql or any other ORM is quick and/or easy to learn. Most people learning LinqToSql struggle with issues around DataContext lifetime management, detaching prior to an update, and many other normal "ORM" issues.
Michael Maddox
I have an application I wrote to give me the code, so writing cookie cutter code isn't much of a problem. I wouldn't mind switching to the Entity framework, but it's unlikely that we will be upgrading to VS2010 for quite a while.
Dan Scott
A: 

Partial classes will help you seperate your code, but the files will have to be in the same project. If you don't want this, why not just inherit new classes from your data-access-classes?

Stephan Keller
A: 

You can move code extracting values from data reader to helper class or to extension methods.

E.g.:

 public int GetIntOrDefault(this DataReader dr, string fieldName, int defaultValue){
     var value = dr.GetOrdinal(fieldName);
     return (!dr.IsDBNull(value)) ? dr.GetInt32(value) : defaultValue;
 }

 internal SomeObject FillDataReader(IDataReader dr)
 {
    SomeObject obj = new SomeObject ();
    obj.ID = dr.GetInt32OrDefault("objectID", 0); // 1 line instead of 4
    ...
    return obj;
 }

This will remedy you for a while, although it I'd recommend to try some ORM. It seems IBatis would be easy to use in your app as you've invested a lot into raw SQL. And many other ORMs are easy too.

elder_george