コントローラーはプレゼンテーション層に属すると聞きました。それはどのように可能ですか?
私はそれを考えました:
- ビューはプレゼンテーション用です
- モデルはビジネス ロジック用です
- コントローラーはロジックを制御するためのものです
コントローラーがプレゼンテーション層に属していることを証明する良いリンクはありますか?
「Spring MVC はプレゼンテーション レイヤーに使用されます」: プレゼンテーション レイヤーでのみ MVC を使用するにはどうすればよいですか?
コントローラーはプレゼンテーション層に属すると聞きました。それはどのように可能ですか?
私はそれを考えました:
コントローラーがプレゼンテーション層に属していることを証明する良いリンクはありますか?
「Spring MVC はプレゼンテーション レイヤーに使用されます」: プレゼンテーション レイヤーでのみ MVC を使用するにはどうすればよいですか?
プレゼンテーション層には、ビューとコントローラーが含まれています。
MVCアーキテクチャを多層/層アーキテクチャ(特に3層アーキテクチャ)と間違えないでください。ほとんどの場合、Model / View / ControllerはWebアプリケーションの主要な設計ではなく、多層/レイヤーアーキテクチャのサブセットにすぎません。
この過度に単純化されたスキームを見てください(専用のデータアクセス層にDAOを置くことができますが、これはこの投稿では重要ではありません):
SpringMVCはプレゼンテーションフレームワークです。コントローラーとビューを処理します。しかし、なぜSpringMVCの「M」なのか。他の多くのプレゼンテーションフレームワークと同様に、モデル/エンティティ( "M")の表現を自然に処理するからです。この表現は、コントローラーで使用され、ビューに表示され、フォームで送信される表現です。そのため、モデル/エンティティがプレゼンテーションレイヤーの一部でなくても、フレームワークはSpringMVCと呼ばれます。
本当に「MVC」指向なので、このフレームワークの良い名前だと思います。実際、モデル/エンティティの表現は次のようになります。
Springの推奨事項は、モデル/エンティティ( "M")オブジェクトを直接使用することです。
再利用可能なビジネスコード、複製の必要はありません。特定のフレームワーク基本クラスを拡張するためにそれらをミラーリングする代わりに、コマンドまたはフォームオブジェクトとして既存のビジネスオブジェクトを使用します。
そのため、フレームワークは、さまざまなフォームオブジェクトを使用する必要があるStrutsなどの他のフレームワークと比較して、非常に「MVC」指向であると言えます。
いくつかの興味深いリンク:
コントローラーは、プレゼンテーション層のロジックを制御します。すべてのビジネス コード、トランザクション ユース ケース、永続性などについて、通常はサービス レイヤーに委任します。
これを行う典型的な方法は、トランザクション サービスを Spring Bean として実装し、それらの Spring Bean をコントローラーに注入することです。典型的な使用例: 新しい製品を作成する:
それは、使用している MVC のフレーバーと、それを使用している環境に大きく依存します。
たとえば、ASP.NET MVC は完全に UI パターンであるため、3 つの部分はすべてプレゼンテーションの一部です。
ただし、MVC のほとんどの実装では、コントローラーはユーザーと対話するため、UI レイヤーの一部です。ボタンの押下やキーボード入力を処理する場合もありますが、多くの場合、コントローラーはモデルとビューを接続する役割も果たします。
普遍的な真実の 1 つは、やむを得ない場合は、コントローラーでビジネス ロジックを実行してはならないということです。ビジネス ロジックが存在する場所は、多くの要因によって異なります。一部の実装ではモデルの一部である場合もあれば、MVC の外部にある独自の別のレイヤーである場合もあります。