NHibernateの基準を抽象化する価値はありますか？

Question

私はNHibernateをかなり新しくしていますが、私が見てきたほとんどの例では、基底であるCriterionまたはDetachedCriterionクラスに抽象レイヤーを追加しています。どこかのサービスまたはリポジトリ層でそのクエリの抽象化は、その後、取得するためにNHibernateはで使用され、適切Criterionオブジェクトに変換され

public class Query<T> 
{ 
    public List<QueryCondition> Conditions { get; set;} 
} 

public class QueryCondition 
{ 
    public string Property { get; set; } 
    public ComparisonEnum Comparison { get; set; } 
    public object Value { get; set; } 
} 

：簡単な例では、それは次のようになりますQueryクラスのいくつかの並べ替えです記録。

この例は、大過剰単純化です。私のプロジェクトでは、ANDとORの条件を含むQuery<T>クラスを作成し、カスタム条件を変換するメソッドを定義しました（この場合は、上記の単純なQueryConditionの例よりはるかに複雑です） AbstractCriterionに追加してサービスに組み込まれたDetachedCriterionに追加します。私がこれをした理由の1つは、ユーザがリストを定義して保存できるようにクエリを関連付けることですが、もっとも大きな理由は、これまで見たn層NHibernateプロジェクトのための一般的な方法であるようです。

しかし、私はこの抽象化のオーバーヘッドがそれに値するかどうか疑問に思っています。それは私にNHibernateの依存関係を保存しません。クエリをバッチ処理するために先物を使用しているので、私のプロジェクトはすべてレコード数のために少なくともIFutureValueにアクセスするためにNHibernateを参照する必要があります。その上、私のQuery<T>クラスは、それがAbstractCriterionを構築するので、NHibernateと密接に結びついています（ただし、別のクラスに簡単に取り込めます）。

私がそれをもっと見ると、Query<T>をDetachedCriteriaに置き換えることができます。どちらもシリアライズ可能なので、私はそれらを保持することができます。基準条件とは別の条件条​​件を作成しないので、複雑なクエリのエイリアス問題に遭遇する可能性は低くなります。そして抽象化が進む限り、これは複雑さから多くの断熱を提供するようには思われません。

NHibernate基準以外の理由を私に教えてもらえますか？「あなたはあなたのORMをいつか変更するかもしれません」（プロジェクトのこの段階では不可能だと思いますか？

Answer 1

これは単体テストの点で有利です。 Criteria APIはクエリを作成するのに本当に優れていますが、実際には嘲笑の痛みです。あなたは、このようなクラスを持っている場合は、簡単に状態を確認します。

query.Conditions.Contains(requiredCondition); 

基準にあなたには、いくつかのモックを必要とし、はるかに困難であるアプリケーションの動作ではなく、出力を確認するだろうが。だからこそ、私はまだ私のアプリでRepositoryパターンを使用しただけではなく、私はまだユニットテストではないよ（私は今SOコミュニティからあえぎを聞くことができます）が、あなたのISession直接