完全に本格的なOR / Mを置き換えるためにdapperを使用する

c# dapper orm

質問

私はDapperマイクロOR / Mに本当に感心しています。私は本当にそれをいくつかの本格的なOR / Mのサイド・バイ・サイド・コンパニオンとして使用したいと思います。とにかく、データベースから階層を非直列化する戦略があれば、私は決して分かりませんでした。たとえば、レコードセット行の返されるオブジェクトは、フィールドに依存します(たとえば、NHの 'discriminator'と呼ばれます)。さらに、階層は結合を介してより多くのテーブルを分割することができるので、行を表すタイプは他のテーブルのレコードの存在に依存します。上記の2つの戦略の混在によって表される階層を持つことは、例えばNHがサポートしていないものであるが、それは「リレーショナル・ライフ」に存在する。だから質問:

  • Dapperはそのようなシナリオを処理しますか?
  • このシナリオはパフォーマンスの面でDapperの努力を犠牲にしますか?

別のトピックはキャッシュです。クエリ用のDapperキャッシュは多少積極的ですが、「セッションのようなコンテキスト」を持ち、各セッションのクエリキャッシュを持っている方が良いわけではないでしょうか、これが再びDapperの主な動機を傷つけますか?

受け入れられた回答

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を生成すると言っても大丈夫です。私は、現在使用されているConcurrentDictionary代わりに独自のキャッシュプロバイダを指定できるフックの追加を完全にサポートしています。



ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow
ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow