1

次のアプリケーションがあるシナリオを考えてみましょう。

  • MVC 4 Web アプリ
  • アプリケーションは、Entity Framework 5 を介して既存のデータベースと通信します (別の ORM またはデータベース プラットフォームに変更する予定はありません)。
  • アプリケーションは外部の SOAP Web サービスと通信します (Web サービスは WCF に変更される場合があります)。

あなたは：

  1. すべての EF エンティティ (MyDBRepository など) 用の汎用リポジトリと、SOAP Web サービス呼び出し用のリポジトリ (MyWSRepository など) を作成します。次に、2 つのリポジトリを使用してデータにアクセスし、すべてのコントローラーのニーズに対応する CRUD メソッドを実装するビジネス ロジックを含むサービス クラスを作成します (MyApplicationService)。次に、リポジトリをサービス クラスに注入し、最後にサービス クラスを MVC コントローラーに注入します。

  2. または、EF によって生成された DBContext と生成されたテーブル エンティティ (MyDBService など) を使用して db クエリとビジネス ロジックを処理する 1 つのサービス クラスと、ビジネス ロジックと SOAP Web サービス呼び出し (MySOAPWebService など) を処理する別のサービス クラスがあります。次に、両方のサービスを MVC コントローラーに挿入します。

  3. または、他の何か。

過去にオプション 1 を使用したことがあります。しかし、それは不要な抽象化レイヤーを追加しているだけなのだろうかと思っています。Entity Framework が DBContext を生成する場合、DBContext エンティティを直接使用するサービス クラスを使用することはそれほど複雑ではないようです。

StackOverflow のいくつかの記事やその他の質問を読んだところ、Service Locator パターンと Repository パターンを区別する灰色の線があるようです。

どの構造を使用しますか?

4

1 に答える 1

1

アグリゲートごとにリポジトリまたは DAO をお勧めします。これらのクラスがコンストラクター (または必要に応じて作業単位) で dbContext を受け取るようにします。

次に、サービスにビジネス ロジックを実装させ、DAO を使用させます。このサービスは、DBContext (および必要な場合はトランザクション) のインスタンス化を担当します。その後、サービスは同じコンテキストで異なる DAO を呼び出します。

より強力なデカップリングのために、サービス レイヤーが DBContext にアクセスできないようにすることを強くお勧めします。毎回DAOを通過するように強制してください。

サービス層も例外を処理する必要があります。私のアプリケーションでは、サービス層はユーザーとシステムの 2 種類の例外のみをスローします。コントローラでは、回復可能なエラーか何かを区別するためにそれらを使用します。(そのため、「無効な注文番号」や「システムでエラーが発生しました。後でやり直してください」などの特定のエラーが表示されることがあります)

ところで、切断されたエンティティで作業することを忘れないでください。追加/更新のためにリポジトリを呼び出すときは、常に POCO が切断されていると想定し、それに応じて作業します。

于 2012-09-05T09:03:13.037 に答える