4

理想的には、Spring MVCアプリケーションのコントローラーは、リクエストを受信し、リクエストをAPIにディスパッチし、（呼び出しの）結果をモデルにロードして（ビューが後でレンダリングするために）、ビューに転送する必要があります。彼らはこれ以上やるべきではありません。

私のコントローラーは今日これよりもはるかに多くのことを行っており、特定の責任をコントローラーから他のAPIに移したいと思います。今日の私のアプリケーション設計（かなり典型的）：

controller <-> Service API <-> DAO <-> DB

今日のコントローラーは、Webアプリが必要とするものとServiceAPIが提供するものとの間のデルタを埋めます。このデルタをかみ砕くコントローラーとサービスAPIの間に追加のレイヤーを配置したいと思います。私の質問は、これらがどのレイヤーであるべきか、そしてこれらの新しいレイヤーの責任は何であるべきかということです。

私の現在のアイデアは次のとおりです

controller <-> controller helper <-> Business API <-> Service API <-> DAO <-> DB

コントローラヘルパー（Webコンテキスト対応-Model、HttpServlet、およびその他のWebコンテキストクラスに依存します）：

  1. エンティティをDTOオブジェクトに変換する（2方向）
  2. IDをエンティティに解決します。たとえば、Controllerは（キーを使用して）学生IDを検索し、それをStudentエンティティに変換します。

ビジネスAPI（Webコンテキストの依存関係なし-JUnitテスト可能）：

  1. ファサードとして機能します。複数のサービスAPIを呼び出して、1つのビジネスリクエストを実現します。
  2. Webアプリ用に特別に調整されたAPIを提供します。

これを別の方法で解決しますか？この特定の問題に関連するリソース（本、記事など）はありますか？

私の質問に答えなかった以前の議論のいくつか：

mvcコントローラーレイヤーの設計

サービス層=アプリケーション層=GRASPコントローラー層

検証、HtmlヘルパーをMVCのサービスレイヤーに移動

ありがとう、Vijay

4

2 に答える 2

1

サービスには、アプリケーションの一般的なビジネス ロジックが含まれています。それらは、コントローラーとDAO/DBの間のほとんどすべてです。

「ビジネスレイヤー」と「コントローラーヘルパー」は単なるサービスです。シンプルにするために、クラシックなデザインを維持します。

Controllers <-> possible Services <-> possible DAOs <-> DB

たまたま同じ種類のロジックを実行するサービスがたくさんある場合 (通常はありません)、当然それらをサブパッケージに分割します。例えば ​​：

  • services.facade または services.business
  • DTO 用の services.adapter (単純なクラスを使用してこのジョブを実行する場合を除く)

ファサード サービスは、次のようにコントローラーによって呼び出されますsomeFacade.someMethod(SomeDTO someDto)。次に、ファサードは、他のサービス (ま​​たは単純なクラス) のおかげで、DTO <-> エンティティ変換を処理します。

それが私があなたの文脈で行う方法です。理想的な世界 (レガシー システムがない、またはゼロからのプロジェクト) では、エンティティを (DTO の代わりに) フォーム オブジェクトとして直接使用し、ほとんどのサービスはファサードになります (可能であれば、残りは単純なクラスになります)。 ）。

于 2012-09-24T21:24:34.523 に答える
0

私はSpring MVCが初めてで、このジレンマにも直面しています。Spring は私にとって初めてのことですが、私は MVC を数年間使用しています。コントローラーは、リクエストを受け入れてディスパッチし、結果を正しい形式でレンダリングするだけでよいことに同意します。ただし、ヘルパーの抽象化が存在するのにサービスが必ずしも最適な場所であるとは限らないと私は考えています。サービスは特定の API をカプセル化して、それ以上のことは何もすべきではないと私は信じています。多くの「タイプ」のサービスを作成すると、このパターンが複雑になり、責任がどこにあるのかが不明確になると思います。

ヘルパーはサービスの兄弟として適していると私は信じています。@Service ではなく @Component で装飾する必要があります。それらの役割は、エンドポイントを通じて公開されたモデルの状態を遷移するために必要な、基礎となる API のファサードとして機能することです。Controller->Helper->[Services] パターンは、関心の明確な分離、コードの再利用性を促進し、高度にテスト可能です。このパターンの性質は、コントローラーの肥大化を防ぐことです。そのため、リクエストをディスパッチしてレスポンスをレンダリングするだけの超薄型コントローラーになってしまいます。

于 2013-12-19T20:59:15.253 に答える