Background

Dapper allows custom Type Handlers and Type Mappers to be provided in order to get the required output from your database. Both of these constructs are used when Dapper dynamically generates deserializer methods using reflection and IL generation.

Whilst this functionality works well 99% of the time, there are certain instances where some more control over deserialization would be beneficial, e.g. a data object containing an enum which cannot be handled by Dapper's current enum handling (a long standing-request).

Proposed Solution

In much the same way that Type Handlers and Type Maps can be configured currently, a new method could be added AddTypeDeserializer<T>(Func<DbDataReader, T>) to allow the custom Type Deserializer to be configured. This custom Type Deserializer would then be returned by GetTypeDeserializer(Type, DbDataReader, int, int, bool) and take full responsibility for creating the result object from the data in the DbDataReader. It would be expected to know how to read the required data from the DbDataReader, regardless of what database query led to its execution since it's provided by the user who is also responsible for the database queries being issued.

Points to consider

1. Custom Type Deserializers should work in much the same way as the dynamically generated Type Deserializers currently emitted by Dapper and so would not allow customisation of simple scalar results that are handled differently.
2. Custom Type Deserializers could be generated by a Source Generator, removing the need for dynamically generated IL