Используя dapper для замены полноценного OR/M

Question

Я действительно впечатлен Dapper micro OR/M, я действительно хотел бы использовать его в качестве соседнего компаньона для какого-либо полноценного OR / M, и я мог бы быть на его месте. В любом случае я не выяснил, существует ли какая-либо стратегия десериализации иерархии из db: например, возвращаемый объект для строки набора записей будет зависеть от поля (например, так называемый "дискриминатор" в NH). Кроме того, иерархия может разделять больше таблиц с помощью объединения, поэтому тип, представляющий строку, будет зависеть от наличия записи в другой таблице. Иерархия, представленная смесью двух вышеприведенных стратегий, может быть чем-то, что NH, например, не поддерживает, но существует в "реляционной жизни". Итак, вопросы:

• Dapper обрабатывает такой сценарий?
• этот сценарий ослабляет усилия Dapper с точки зрения производительности?

Другая тема - кеширование. Кэш Dapper для запросов немного агрессивен, не лучше ли иметь некоторый "контекст, подобный сеансу" и иметь кэш запросов для каждого сеанса, или это опять-таки нарушит основные мотивы Dapper?

Answer 1

На данный момент 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 используется сейчас.