using dapper to replace a fully fledged OR/M

Question

I'm really impressed by Dapper micro OR/M, I really would like to use it as a side by side companion of some fully fledged OR/M, and my be evantually in place of it. I did not figure out anyway if there is some strategy to deserialize a hierarchy from db: for example the returned object for a recordset row would depend on a field ( the so called 'discriminator' in NH for example ). Furthermore the hierarchy can split more table via a join, so the type that represent the row will depend on the existence of the record in the other table. Having a hierarchy represented by a mixture of the two strategy above would be something that NH for example does not support, but that exist in the 'relational life'. So the questions:

• does Dapper handle such a scenario ?
• does this scenario wanish the Dapper efforts in term of performance ?

Another topic is caching. Dapper cache for queries is a little to much aggressive, wouldn't be better to have some "session like context" and have a query cache for each session, or would this again offend the main Dapper motivations ?

Answer 1

At the moment Dapper does not support custom construction logic, I guess what you are asking for is something like:

class Post {}
class Question : Post { .. }
class Answer : Post { ... }

Func<IDbDataReader, Func<IDbDataReader, Post>> factoryLocator
        = ... my magic factory locater; 

cnn.Query<Post>(@"
select * from Posts p 
left join Questions q on q.Id = p.Id 
left join Answers a on a.Id = p.Id", factoryLocator: factoryLocator);

We decided against implementing such logic cause we never really had to solve a problem like this in real life. It also introduces a fair amount of internal complexity and a fair amount of external complexity (as you need to switch on post is Question).

I am not categorically against including this kind of feature if you can make a good argument for inclusion and the patch is simple. I am also all for adding hooks in Dapper to allow you to inject this kind of functionality.

As to the caching strategy, we find that in general use we never ever bloat the cache, bloating only happens if you are misusing dapper by say, generating unparameterized SQL. I totally support adding a hook that would allow you to specify your own cache provider instead of the ConcurrentDictionary used now.