1

私のさまざまなプロジェクトでは、コマンド/クエリ分離パターンを実装し、NHibernate を ORM として使用しています。

一般に、コマンドとクエリはUserManagement、TagManagement、QuestionManagementなどの特定の一連のアクティビティに関連する別のプロジェクトに保持します。

簡単に見つけられる機能を備えたこれらのリポジトリにすべてをうまく分割するのがとても好きです。このように物事を行うことには確かに利点があります。

しかし、特に NHibernate がすでにそのような強力な抽象化を提供していることを考えると、基本的なクエリに対するこの抽象化の価値について疑問に思い始めています。

私のMVCコントローラーでこれを考慮してください： 

_nHibernateSession.Get<UserProfile>(_sessionData.UserId);

これをリポジトリのクエリに抽象化できましたUserManagementが、それがどのような価値を提供するのかわかりません。

どう思いますか？すべてをコマンド/クエリ パラダイム内に保持しますか?それとも、このような単純な要求のためにコントローラで nhibernate セッションを直接使用しますか?

4

3 に答える 3

3

通常、私はリポジトリを使用していません。コードに抽象化を追加しすぎていると思うからです。Service / Controllerレイヤーで直接構築されるView Modelを好みます。単体テストを書きたい場合は、サービスまたはコントローラーに対して書くことができます。いくつかのクエリ基準を再利用したい場合は、拡張メソッドを書くだけです:

    public static IQueryable<User> Administrators(this IQueryable<User> users)
    {
        return users.Where(x => x.Role.Id == Role.Const.Admin);
    }

これに関しては、次の記事をお勧めします : http://ayende.com/blog/3955/repository-is-the-new-singleton all-about-the-repository-anti-pattern/

于 2012-06-01T12:20:26.130 に答える
2

私はすべてのクエリをリポジトリに保持することを好みます。多くの異なるクエリを作成する必要がある場合は、IQueryable を実装するリポジトリを公開し、セッションをラップできます。LINQ To Nhibernate のクエリには、HQL または基準に関する制限があります。

しかし、私にとっては、これを行う正当な理由はありません。データ アクセス レイヤーを他の誰かに提供していて、クエリがわからない場合に限られます。

この例は、私が取り組んでいる DDDプロジェクトで見ることができます。

于 2012-06-01T11:58:47.973 に答える
1

特に MVC コントローラーの単体テストを行う必要がある場合は、MVC コントローラーと NHibernate の間で一定レベルの抽象化を維持することを強くお勧めします。リポジトリ レイヤーがなければ、リポジトリ レイヤーのモックを必要とする単体テストを作成することははるかに困難です。

于 2012-06-01T12:00:32.787 に答える