Mapping table-value parameters

[Stan-RED]

Dapper is know as an object mapper tool, but when we deal with TVPs (table-value params) ther is a lack of mapping. Currently only DataTable and SqlDataRecord[] are supported which are a huge distance away from POCO. In ORM worls such tables are represented as IEnumerable.

In my ongoing project I have implemented a quickfix for this and decided to share idea with you. Some notes:

1. It's not ideal, because honestly I don't understand some accessibility conventions (e.g. all TVP-related classes are internal), some SOLID things (mapping tool has no good interface to get type mapping, SqlMapper depends on details like SqlDataRecordListTVPParameter, etc).
2. I've tried to accomplish Dapper's vision and make it fast using cashing and runtime compilation.

Probably this will address #541, #201, #807, #389.

[Jetski5822]

Really nice work dude!

[adnang]

This work was done a while ago and would really make some of work i'm currently doing easier. Could this be merged in and released?

[Stan-RED]

@Jetski5822 thank you! ✋

[Stan-RED]

@adnang I thought to publish it as a separate package, because it's working successfully in a high-load project for more than 1 year. But unfortunately OCP principle wasn't a part of Dapper's vision so I had to use some internals and such package will be hacky.

[dzolnjan]

I could really use this feature in my current project. Any update on if/when it would be released?

[Zubaloo]

This line looks to be redundant.

[NickCraver]

@StanEgo We dropped the ball responding here, not returning to it after System.Data.SqlClient vs Microsoft.Data.SqlClient discussions - Dapper not depends on neither and that was going to affect PRs like this.

By necessity of referencing types, it needs to be a separate package, but I am curious what internals you'd need to make that possible. I'm not quite sure how you'd gracefully handle both SQL clients (it's a bit of a mess, in some situations, so depends how deep you get). It seems like you went down the separate package route at least somewhat, any chance you still remember what else would need to be exposed to make this work cleanly that way?

[Stan-RED]

@NickCraver, unfortunately it's not in my cache right now. But I glanced at the projects it is used in and can say that it easily migrated to Microsoft.Data.SqlClient (only usings changed from System.Data.SqlClient/Microsoft.SqlServer.Server to Microsoft.Data.SqlClient/Microsoft.Data.SqlClient.Server). It also works with the most actual Dapper 2.0.90 without any hacks (except using LookupDbType method marked as obsolete and commented as for internal usage only, but still public).

Completely agreed that having it in a separate MSSQL-related package, keeping Dapper core based on the abstractions is a good idea.

Maybe it would be better also to implement another extensibility point for type providers (like it is done for mappings and even some poor-man solution for bulk copy providers). So things like

Dapper/Dapper/SqlMapper.cs

Line 409 in 29f3bef

case "Microsoft.SqlServer.Types.SqlGeography":

can be moved there as well. I understand that putting "Microsoft.SqlServer.Types.SqlGeography" as a string is not de jure a dependency, but come on))