Comments on: When an object-relational mapper is too much, DataReader too little

By: Abusing dynamic for no good reason « Searching, Seek and Deploy

Abusing dynamic for no good reason « Searching, Seek and Deploy — Sun, 28 Feb 2010 16:54:49 +0000

[...] Guard had a short post “When an object-relational mapper is too much, DataReader too little” along these lines and that’s what i have used as the basis for my dynamic abuse. In [...]

By: Jimmy Zimmerman

Jimmy Zimmerman — Mon, 05 Oct 2009 18:24:59 +0000

Yeah I actually hooked this guy up with another Ex Method from Alex (http://www.base4.net/blog.aspx?ID=409 which appears now to be DOA). Which was something along the lines of:

public static IEnumerable Enumerate(this IDataReader reader) {
  using (reader) 
    while (reader.Read())
      yield return reader;
}

It seems logical that we really have two responsibilities here. One to enumerate a sequence of IDataRecord instances and another to coordinate with a mapping delegate and our friend the ExecuteReader() method.

By: Damien Guard

Damien Guard — Fri, 02 Oct 2009 00:29:16 +0000

@Jimmy: Good call, switched to IDataRecord :)

By: Jimmy Zimmerman

Jimmy Zimmerman — Tue, 29 Sep 2009 22:57:04 +0000

The map function should be typed to a Func interface instead of the abstract DbDataReader class. One, the DbDataReader really is a bootstrap implementation of IDataReader and since you are really trying to perform reification of an object against a single “row”, you only need to expose the IDataRecord interface. I totally support the whole caveat emptor concept and that if someone does something stupid in the map delegate, like calling IDataReader.Read(), then that’s their fault. However, I also strongly believe in the intention revealing interface. Basically if I see a parameter of type Foo in a delegate parameter definition, in theory all the operations available defined on Foo should be callable by me. That’s not really the case here, you only want the IDataRecord members called (i.e.GetString(), GetInt32(), etc). Just my 2 cents.

-jimmy

By: Damien Guard

Damien Guard — Fri, 25 Sep 2009 00:32:28 +0000

@Matt Yes, AutoMapper might well be worth trying once the prototype gets a bit bigger :)

[)amien

By: Matt Burton

Matt Burton — Thu, 24 Sep 2009 20:02:32 +0000

Another option is Jimmy Bogard's AutoMapper - has support for IDataReader and IDataRecord built-in now. One line to map IDataReader to your type: Mapper.CreateMap(); And another to do the map:

var customers = Mapper.Map(dataReader);

Could probably bake that into your extension method style quite nicely:

public static class DataHelpers {
    public static IEnumerable As(this DbCommand command) {
        using (var reader = command.ExecuteReader(CommandBehavior.CloseConnection)) {
            return Mapper.Map(dataReader);
        }
    }
}

Or heck, skip the CreateMap step if you don't need anything fancy (i.e. your domain object properties are 1-1 with column names) and change that line in the extension to this:

return Mapper.DynamicMap(dataReader);

By: Mike Levy

Mike Levy — Thu, 24 Sep 2009 12:35:42 +0000

Give IBatis.Net a quick look: http://ibatis.apache.org/index.html

By: Rob

Rob — Thu, 24 Sep 2009 07:52:46 +0000

isn’t ToList already an extension method in System.Linq.Enumerable?

By: Kevin Babcock

Kevin Babcock — Thu, 24 Sep 2009 03:23:40 +0000

While I like the approach, I agree with Zihotki: DbDataReader object should be closed as early as possible. This approach could hurt scalability.

By: Rob Conery

Rob Conery — Wed, 23 Sep 2009 18:25:11 +0000

Well I was going to tell you that you could use SubSonic for this (sans code generation):

var customer = new CodingHorror("SELECT * FROM Customer WHERE ID=@1",1).ExecuteSingle();

But if you think FluentADO is "too big" then you might think SubSonic is as well :).