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

Question

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

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

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

Answer 1

На данный момент Щеголеватый не поддерживает пользовательскую строительную логику, я предполагаю, что вы просите что-то вроде:

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.