Enhance Dapper to support DataSets

[GoogleCodeExporter]

Using Dapper 1.12.1 on .NET 3.5

I have a legacy code base with Sql Server data access code that uses DataSets 
as well as POCO objects.

I'd like to be able to use Dapper's DynamicParameters support to generate 
parameters for SELECT queries that are used to fill a DataSet.  As far as I can 
see this might be possible with a suitable public overload of 
SqlMapper.SetupCommand, or maybe some public API to convert DynamicParameters 
into a list of SqlParameter objects.

This would enable me to have developers use a consistent method for generating 
parameters, whether used by Dapper or for filling a DataSet.

Original issue reported on code.google.com by Jocular...@hotmail.com on 14 Oct 2013 at 4:05

[GoogleCodeExporter]

I'm not alone in this - here's a StackOverflow question from someone looking 
for essentially the same thing: 
http://stackoverflow.com/questions/17755373/report-viewer-x-dapper.

I'd like to be able to achieve this without customising the Dapper source code.

I'd like to emphasise that I'm aware that Dapper can't / shouldn't provide full 
support for DataSets, but nevertheless, for consistency, I'd like to be able to 
use Dapper's DynamicParameters in all my data access code.

Original comment by Jocular...@hotmail.com on 15 Oct 2013 at 6:02

[GoogleCodeExporter]

I created a fork where I added support for DataSets/DataTables.

I created a pull request here: 
https://github.com/SamSaffron/dapper-dot-net/pull/98

Original comment by sectr...@gmail.com on 24 Oct 2013 at 2:22

[GoogleCodeExporter]

On a similar note, I've seen requests to allow the materialization half of 
dapper available to people who already have a data-reader. I'll have to see if 
there is a sensible way of splitting the two APIs, so that we have:

- execute a command, obtaining a reader (which can be fed directly to DataTable)
- take a reader, and run the materialization

One problem with the second of these is that the meta-programming cache uses 
the command information... but the first should be fairly easy.

Original comment by marc.gravell on 24 Oct 2013 at 9:18

[GoogleCodeExporter]

> I'll have to see if there is a sensible way of splitting the two APIs

This sounds like a good idea, though isn't it three APIs really:

- Generation of parameters
- Generation of the materialization function
- Caching of the materialization function

Would it be possible to expose also the generation of the materialization 
function (which is presumably a Func<IDataRecord, T>), so that users can choose 
to implement their own caching as an alternative to using Dapper's static 
dictionary.

Original comment by Jocular...@hotmail.com on 27 Oct 2013 at 2:36

[GoogleCodeExporter]

I've created a fork where I've added an ExecuteReader method, which I think is 
all is needed to support DataSets, and a pull request here:

https://github.com/SamSaffron/dapper-dot-net/pull/103

Original comment by Jocular...@hotmail.com on 7 Nov 2013 at 5:00