I want to elaborate on my main ideas from my presentation about Code Templating - abstracting your code via delegates & anonymous methods. During the presentation, I talked about solutions to repetitive, every-day tasks. One of the examples I presented was something *we are all familiar with and that is querying our database. Lets take a look shall we?

public static List<User> GetUsersList()
{
   using (SqlConnection conn = new SqlConnection(ConnectionString))
   {
      SqlCommand cmd = new SqlCommand("Select Id, Name From Users", conn);

      conn.Open();

      List<User> users = new List<User>();

      SqlDataReader r = cmd.ExecuteReader();
      while (r.Read())
      {
         User u = new User();
         u.Id = Convert.ToInt32(r["Id"]);
         u.Name = Convert.ToString(r["Name"]);

         users.Add(u);
      }

      return users;
   }
}

Now let's imagine that we also have Get*List for Products, Orders, Items and Sales. That's 5 Get*List methods already. Let's look at the code that is common among those potential methods (in red):

public static List<User> GetUsersList()
{
   using (SqlConnection conn = new SqlConnection(ConnectionString))
   {
      SqlCommand cmd = new SqlCommand("Select Id, Name From Users", conn);

      conn.Open();

      List<User> users = new List<User>();

      SqlDataReader r = cmd.ExecuteReader();
      while (r.Read())
      {
         User u = new User();
         u.Id = Convert.ToInt32(r["Id"]);
         u.Name = Convert.ToString(r["Name"]);

         users.Add(u);
      }

      return users;
   }
}

So the first solution to refactor those lines of (repetitive)code out will be, obviously, via OOP.
Here is a quick solution I came up with just to make the point clear:

static class DbServices
{
   public static TRet ExecuteReader<TRet>(
      IDbCommand cmd, 
      IDataReaderParser<TRet> parser)
   {
      using (SqlConnection conn = new SqlConnection(ConnectionString))
      {
         cmd.Connection = conn;

         conn.Open();

         IDataReader reader = cmd.ExecuteReader();

         return parser.Parse(reader);
      }
   }
}

So far we have some "parser" interface which will get a liveReader and return some generic type based on the required parsing. I don't know if you've noticed but DbServices.ExecuteReader holds all the lines I marked with red just before. 

Let's look at our GetUsers parser:

class GetUserListParser : IDataReaderParser<List<User>>
{
   public List<User> Parse(IDataReader liveReader)
   {
      List<User> users = new List<User>();

      while (liveReader.Read())
      {
         User u = new User();
         u.Id = Convert.ToInt32(r["Id"]);
         u.Name = Convert.ToString(r["Name"]);

         users.Add(u);
      }

      return users;
   }
}

Our parser get the live IDataReader and returns a list of users. Simple.
GetUsersListParser.Parse method contains the rest of the code (all code minus code in red) from our original GetUsersList method.

Finally, our GetUsersList method looks like this:

public static List<User> GetUsersList()
{
   SqlCommand cmd = new SqlCommand("Select Id, Name From Users");

   GetUserListParser parser = new GetUserListParser();

   return DbServices.ExecuteReader<List<User>>(cmd, parser);
}

That's nice, but is it good enough ?? 
For every Get*List method we will have to build a separate class which will implement IDataReaderParser<TRet>. Let's pause here.

* breath.... good .... *

Let's rewind. When I started writing the original GetUsersList method, my main goal were those lines:

// (1) Create command
SqlCommand cmd = new SqlCommand("Select Id, Name From Users");

// (2) In some magical way, execute the command and return a live reader so I can parse it into objects.
List<User> users = new List<User>();

while (liveReader.Read())
{
   User u = new User();
   u.Id = Convert.ToInt32(r["Id"]);
   u.Name = Convert.ToString(r["Name"]);

   users.Add(u);
}

return users;

Open a connection against the database, executing the command as reader and disposing the connection were irrelevant at the time, I knew that I will have to write those lines down but they were just means to get to my real goal(=my real code). So I refactored my code via some sort of OOP solution.

Now I have pieces of code all over the place and even worse - in 1-2 months from now I will have to "Go To Definition" just to remember what the hack is GetUsersListParser class.

My main code was refactored out of my method.

Life shouldn't be so hard. Like a very wise(and old, they are always old) programmer once said: "If you code it, it will come;".
Let's look at a different solution - let's abstract our code via delegates & anonymous methods.

So our DbServices.ExecuteReader<TRet> will look like:

public delegate TRet ReaderHandler<TRet>(IDataReader liveReader);


static class DbServices
{
   public static TRet ExecuteReader<TRet>(
      IDbCommand cmd, 
      ReaderHandler<TRet> handler)
   {
      using (SqlConnection conn = new SqlConnection(ConnectionString))
      {
         cmd.Connection = conn;

         conn.Open();

         IDataReader reader = cmd.ExecuteReader();

         return handler(reader);
      }
   }
}

DbServices.ExecuteReader receive a (Sql)command to execute and an "handler" - a method with the same signature as ReaderHandler<TRet> delegate. ExecuteReader method will execute the command as a reader and send it(the reader) to the method handler. So who is this "handler" I talk about so much ?! The anonymous method !!

Let's look at the new version of GetUsersList:

public static List<User> GetUsersList()
{
   SqlCommand cmd = new SqlCommand("Select Id, Name From Users");

   return DbServices.ExecuteReader<List<User>>(cmd,
      delegate(IDataReader liveReader) <-- our handler, inline
      {
         List<User> users = new List<User>();

         while (liveReader.Read())
         {
            User u = new User();
            u.Id = Convert.ToInt32(liveReader["Id"]);
            u.Name = Convert.ToString(liveReader["Name"]);

            users.Add(u);
         }

         return users;
   });
}

The entire logic is just in front of me now, no need to start smelling around it !

Just like in the first OOP solution, I don't need to handle the connection, call the ADO.NETs' ExecuteReader, nothing.

To sum up:

Delegates & anonymous methods       1 : 0       OOP

Think about solutions you've implemented via OOP and start thinking about delegates as an alternative abstraction technique. For many straight forward architectural problems, delegates will be by far a better solution than traditional OOP.

My next post on this matter will cover the expected question - when delegates solution is too complex??

* Well, most of us anyway. For the rest of you - be cool and play along.