6

私は Dapper micro OR/M に本当に感銘を受けました。本格的な OR/M と並べて使用したいと思っています。データベースから階層を逆シリアル化するための戦略があるかどうか、とにかくわかりませんでした。たとえば、レコードセット行の返されるオブジェクトはフィールドに依存します（たとえば、NHのいわゆる「ディスクリミネーター」）。さらに、階層は結合を介してさらに多くのテーブルを分割できるため、行を表すタイプは他のテーブルのレコードの存在に依存します。上記の 2 つの戦略の混合によって表される階層を持つことは、たとえば NH ではサポートされていませんが、「リレーショナル ライフ」に存在します。だから質問：

  • Dapper はそのようなシナリオを処理しますか?
  • このシナリオは、パフォーマンスの点で Dapper の取り組みを弱めますか?

もう 1 つのトピックはキャッシングです。クエリの Dapper キャッシュは少し積極的です。「コンテキストのようなセッション」を持ち、セッションごとにクエリ キャッシュを用意するのは良くないでしょうか。それとも、Dapper の主な動機に反するのでしょうか?

4

1 に答える 1

5

現時点では、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 にフックを追加することにも賛成です。

キャッシング戦略に関しては、一般的な使用ではキャッシュを肥大化させることは決してないことがわかりました。肥大化は、パラメーター化されていない SQL を生成するなど、dapper を誤用している場合にのみ発生します。現在使用されているものではなく、独自のキャッシュ プロバイダーを指定できるようにするフックの追加を完全にサポートしますConcurrentDictionary。

于 2012-05-09T06:13:59.283 に答える