2017-01-08 18 views
0

コントローラからビジネスロジッククラスをできるだけ少なくするように、コントローラからビジネスロジッククラスを分離しました。しかし、私は同じdbcontext througoutをWebリクエストの生涯にわたって使いたいので、コンテキストをライブで持つentitesを渡せるようにするために、dbcontextをビジネスロジッククラスに渡しています。これらのクラスのほぼすべてのメソッドは受け入れますdbcontextをパラメータとして使用します。 (コンテキストが異なると、同じエンティティを生成するためにデータベースにクエリを実行する必要があります)dbcontextの再利用

この方法に問題はありますか? (同じコンテキストを使用し、それぞれのビジネスロジックメソッドのパラメータとして受け入れるという点で)

+0

データアクセスレイヤーはすべてのDB固有のロジックを処理する方が良いでしょう.Business Logicは、コンテキストe.t.cのようなDB固有の詳細を知ってはいけません。コンテキストの存続期間は、IoCコンテナ(Singleton要求またはOne要求)を介して1つのコンテキストインスタンスを制御する方が適しています。 – Vladimir

答えて

0

私はあなたのプロジェクトにリポジトリと作業単位デザインパターンを実装するべきだと思います。

リポジトリと作業パターンの単位は、あなたがビジネスロジックの分離を、すべての準備ができてやった

データアクセス層とアプリケーションのビジネスロジック層との間に抽象化レイヤーを作成することを意図しています層とデータアクセス層。 dbcontextを共有するために作業単位パターンを使用する必要があります。

ワーク・クラスのユニットは

が実装hereについてもっと知るそれらのすべてによって共有される単一のデータベース・コンテキスト・クラスを作成することにより、複数のリポジトリの作業を調整します。

+0

私の答えをチェックしましたか? –