Let's make the type mapper more pluggable.

I'm seeing a big picture of a lot of issues solved in a single way here. People want to slightly adjust how the type mapping works in various ways - and I think we can do a better job of allowing this.

Here are some examples:

• #376 Changing the mapping using a [Column] attribute (I'm thinking [DataMember])
• #360 Customizing the Query<T> mapper
• #350 More automated multi-mapping
• #326 An Azure-side issue with Id columns that could possibly be worked around
• #319 Changing how TimeSpan maps
• #254 Option to throw with unmapped columns (use cases for both directions)
• #251 Colmaps for Oracle
• #198 Supporting Nodatime

This one is a more questionable example (as in questionable if this would help):

• #262 Query abstract types

There may be a few I missed, but you get the idea. You can replace the DefaultTypeMap since #110 was merged a few weeks ago. However, we can do better here by allowing DefaultTypeMap to be plugged a bit rather than clipboard inherited all over. We'd also need to look at what functionality could move down into it to be pluggable (such as column names).

I'm not arguing for this to all be in core - I honestly think it'd be a bad idea if all of it was. I think making it pluggable makes some of the odder cases, if common, appear as mappers you could easily plug in from contrib. For example, what if #376 could be fixed by:

SqlMapper.TypeMapProvider = t => Dapper.Contrib.DataMemberMapper;

and #350 by:

SqlMapper.TypeMapProvider = t => MyCustomMultiMapper;

Posting this here for thoughts.

Start with DefaultTypeMap and the SqlMapper.TypeMapProvider extension point described in the issue, then review the related issues #376, #360, #350, and #319 to identify common requirements. The work is done when the project has an agreed pluggable type-mapping design, with the relevant behavior covered by tests and a clear boundary for contrib extensions.