使用Dapper替代完整的ORM

Question

使用Dapper替代完整的ORM

6

我对Dapper微型OR/M印象深刻，我真的很想将其用作一些完整的OR/M的伴侣，甚至可能替代它。但我没有找到任何方法来反序列化数据库中的层次结构：例如记录集行的返回对象将取决于字段（在NH中称为“标识符”）。此外，层次结构可以通过联接分割更多的表，因此表示行的类型将取决于其他表中记录的存在。使用上述两种策略混合表示的层次结构是 NH 等不支持的，但“关系生活”中存在。所以问题是：

Dapper是否处理这种情况？
这种情况是否会影响Dapper的性能？

另一个话题是缓存。Dapper查询缓存有点过于激进，难道每个“类似会话的上下文”都有一个查询缓存，这样就好了，还是这会影响Dapper的主要动机？

- Felice Pollano

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Sam Saffron · Accepted Answer

目前，Dapper不支持自定义构造逻辑。我猜你所要求的是这样的内容：

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);

我们决定不实现这种逻辑，因为我们在现实生活中从未真正解决过这样的问题。它还会引入相当数量的内部复杂性和外部复杂性（因为您需要切换到 post is Question ）。如果您能为其包含提供一个很好的理由并且补丁很简单，我不会绝对反对包含这种功能。我也完全赞成在Dapper中添加钩子，以允许您注入此类功能。

至于缓存策略，我们发现在一般使用中，我们从不产生缓存膨胀，只有在错误使用dapper时才会发生膨胀，例如生成非参数化SQL。我完全支持添加一个钩子，允许您指定自己的缓存提供程序，而不是现在使用的ConcurrentDictionary。