我见过使用反射和属性或字段上的属性将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（）是扩展方法）
如果 ，你很可能会使用更好的NHibernate，EF或LINQ到SQL等 但是在旧的项目（或其他（有时是有效的）的原因，如“非我发明”，“存储特效的爱”等）并非总是可以使用ORM，因此重量更轻的系统对于“袖手旁观”很有用。
如果您每个人也需要编写大量IDataReader循环，那么您将看到减少编码（和错误）的好处， 使用的系统 。这并不是说它是一个很好的体系结构。
我假设CustomerDTO不会走出数据访问层，而复合对象等将由使用DTO对象的数据访问层建立。
在我写了这个答案的几年后，Dapper进入了.NET的世界，这可能是编写onw AutoMapper的一个很好的起点，也许它将完全消除您这样做的需要。
602392714
清零编程群