クエリを置く場所 - モデルとコントローラ

architecture asp.net-mvc-3 dapper

質問

はActiveRecord / NHibernateからDapperに切り替えました 。以前は、コントローラですべてのクエリを実行していました。しかし、私のモデルに実装するのに便利ないくつかのプロパティ(集計/合計/合計/平均など)では、私のモデルのインスタンス変数(コレクション)を反復して計算することができました。

具体的には、私のProjectAppSessionsという概念がAppSessions 、いくつかのsomeProject.AppSessions反復することで、セッションの合計数と平均セッション長を計算できます。

Dapperを使っているので、これは混乱しているようです。私のコントローラメソッドは、Dapper(これは大丈夫です)を介してデータベースにクエリを実行しますが、私のモデルクラスはDapper(奇妙なことです)を介してデータベースにクエリを行います。

TLDR:DBアクセスは私のモデル、コントローラ、またはその両方に行かなければなりませんか?どちらも正しいとは思われません。後でDBアクセススタイルを変更してもあまり影響を与えないように、1つの「レイヤー」に制限したいと思います。

受け入れられた回答

リポジトリパターンの使用を検討する必要があります

リポジトリを使用すると、すべてのデータベース問合せが、パブリック・インタフェースを介して公開されているリポジトリ内にカプセル化されます。次に例を示します。

public interface IGenericRepository<T> where T : class
{
    T Get(object id);
    IQueryable<T> GetAll();
    void Insert(T entity);
    void Delete(T entity);
    void Save(T entity);
}

次に、リポジトリをコントローラに注入することができます。

public class MyController
{
    private readonly IGenericRepository<Foo> _fooRepository;
    public MyController(IGenericRepository<Foo> fooRepository)
    {
        _fooRepository = fooRepository;
    }   
}

これにより、UIにDB依存関係がなくなり、テストが容易になります。単体テストからIRepositoryを実装したモックを注入できます。これにより、リポジトリは、DapperやEntity Frameworkなどのテクノロジをクライアントの変更や随時の実装や切り替えが可能になります。

上記の例では汎用リポジトリを使用していましたが、そうする必要はありません。 IFooRepositoryなどのリポジトリごとに個別のインタフェースを作成することができます。

リポジトリパターンを実装する方法の多くの例と多くのバリエーションがありますので、Googleで理解してください。ここに私の好きな記事があります。 階層化されたアーキテクチャ

もう一つの注意:小規模なプロジェクトでは、コントローラにクエリを直接入れることはOKです。


人気のある回答

私はリポジトリモデルに関して@ void-rayに同意します。しかし、インターフェースや依存関係注入をしたくない場合でも、データアクセス層を分離し、静的メソッドを使用してDapperからデータを返すことができます。

私がDapperを使用しているときは、通常、非常に小さなオブジェクトやリストを返すリポジトリライブラリがあり、ViewModelにマッピングしてViewに渡すことができます(マッピングはStructureMapによって行われますが、コントローラや他のヘルパーで処理できます) 。



ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow
このKBは合法ですか? はい、理由を学ぶ
ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow
このKBは合法ですか? はい、理由を学ぶ