MapDataReader 1.0.4

MapDataReader

Super fast mapping DataReader to a strongly typed object. High performance, lighweight (12Kb dll), uses AOT source generation and no reflection, mapping code is generated at compile time.

Benchmarks

20X faster than using reflection, even with caching. Benchmark for a tiny class with 5 string properties:

Install via Nuget

Install-Package MapDataReader

Usage

using MapDataReader;

[GenerateDataReaderMapper] // <-- mark your class with this attribute
public class MyClass
{
	public int ID { get; set; }
	public string Name { get; set; }
	public int Size { get; set; }
	public bool Enabled { get; set; }
}

//ToMyClass() method code is generated at compile time
List<MyClass> result = dbconnection.ExecuteReader("SELECT * FROM MyTable").ToMyClass();

Some notes

• The ToMyClass() method above - is an extension method generated at compile time. You can even "go to definition" in Visual Studio and examine its code.
• The naming convention is ToCLASSNAME() we can't use generics here, since <T> is not part of method signatures in C# (considered in later versions of C#).
• Maps properies with public setters only.
• The reader is being closed after mapping, so don't reuse it.
• The example above uses .ExecuteReader method from Dapper, but you can generate the reader in any way you want, e.g. the plain SqlCommand.ExecuteReader will also work.
• Supports enum properties based on int and other implicit casting (sometimes a DataReader may decide to return byte for small integer database value, and it maps to int perfectly via some unboxing magic)
• Properly maps DBNull to null.
• Complex-type properties may not work.
• netstandard 2.0
• Contributions are very welcome.

P.S. Using it with Dapper

If you're already using the awesome Dapper ORM by Marc Gravel, Sam Saffron and Nick Craver, this is how you can use our library to speed up DataReader-to-object mapping in Dapper:

// override Dapper extension method to use fast MapDataReader instead of Dapper's built-in reflection
public static List<T> Query<T>(this SqlConnection cn, string sql, object parameters)
{
	if (typeof(T) == typeof(MyClass)) //our own class that we marked with attribute? use MapDataReader
		return cn.ExecuteReader(sql, parameters).ToMyClass() as List<T>;

	if (typeof(T) == typeof(AnotherClass)) //another class we have enabled? use MDR
		return cn.ExecuteReader(sql, parameters).ToAnotherClass() as List<T>;

	//fallback to Dapper by default
	return SqlMapper.Query<T>(cn, sql, parameters).AsList();
}

Why the C# compiler will choose your method over Dapper's?

When the C# compiler sees two extension methods with the same signature, it uses the one that's "closer" to your code. "Closiness" - is determined by multiple factors - same namespace, same assembly, derived class over base class, implementation over interface etc. (go read the article linked above). Adding an override like this will silently switch your existing code from using Dapper/reflection to using our source generator (b/c it uses a more specific connection type and lives in your project's namescape), while still keeping the awesomeness of Dapper and you barely have to rewrite any of your code.