我见过使用反射和属性或字段上的属性将DataReader映射到对象的系统。（有点像什么呢LinqToSql。）他们节省一点打字和编码的DBNull等时，一旦缓存生成的代码，他们可以更快那么大多数手工编写代码，以及可减少错误的数量，所以不要
考虑 了如果您经常这样做，则是“公路”。

有关此示例，请参阅“ .NET中的反射防御”。

然后，您可以编写如下代码

class CustomerDTO  
{
    [Field("id")]
    public int? CustomerId;

    [Field("name")]
    public string CustomerName;
}

…

using (DataReader reader = ...)
{    
   List<CustomerDTO> customers = reader.AutoMap<CustomerDTO>()
                                    .ToList();
}

（AutoMap（）是扩展方法）

@Stilgar，感谢一个 伟大的 评论

如果 能 ，你很可能会使用更好的NHibernate，EF或LINQ到SQL等
但是在旧的项目（或其他（有时是有效的）的原因，如“非我发明”，“存储特效的爱”等）并非总是可以使用ORM，因此重量更轻的系统对于“袖手旁观”很有用。

如果您每个人也需要编写大量IDataReader循环，那么您将看到减少编码（和错误）的好处， 而不必更改正在 使用的系统 的体系结构
。这并不是说它是一个很好的体系结构。

我假设CustomerDTO不会走出数据访问层，而复合对象等将由使用DTO对象的数据访问层建立。

在我写了这个答案的几年后，Dapper进入了.NET的世界，这可能是编写onw
AutoMapper的一个很好的起点，也许它将完全消除您这样做的需要。