Java での Web MVC のグラフィカルな紹介

MVC モデルは、それ自体が新しい機能を導入するものではなく、表示とモデル、プロセス制御ロジック、ビジネス ロジック呼び出しと表示ロジックをより合理的に整理するのに役立ちます。開発中の Web リクエスト/レスポンス モデル:

Web の世界では、具体的な手順は次のとおりです:

1. Web ブラウザ (IE など) がリクエストを開始します。

2. Web サーバー (Tomcat など) はリクエストを受信し、リクエストを処理し (たとえば、ユーザーが追加された場合はユーザーが保存されます)、最後にレスポンス (通常は HTML) を生成します。

3. Web サーバーは処理を完了すると、コンテンツを Web クライアント (通常はブラウザ) に返し、クライアントは受信したコンテンツを処理します (たとえば、Web ブラウザは受信した HTML コンテンツを顧客に表示するためにレンダリングします)。 。

したがって、Web の世界では、

リクエストを開始するのは Web クライアントであり、Web サーバーは応答を受信、処理し、生成します。

通常、Web サーバーは Web クライアントにコンテンツを更新するように積極的に通知できません。現在、サーバー プッシュ (Comet など) や現在の HTML5 WebSocket などのテクノロジーがいくつかありますが、Web サーバーは Web クライアントにアクティブに通知できます。

Web 開発におけるリクエスト/レスポンス モデルを理解したところで、標準の MVC モデルが何であるかを見てみましょう。

標準 MVC モデルの概要

MVC モデル: これは、新しい機能自体を導入するものではなく、表示をモデルやプロセスから分離するのに役立つだけです。制御ロジック、ビジネスロジック呼び出しロジックと表示ロジックが分離されています。図 1-2 に示すように

図 1-2

まず、MVC (Model-View-Controller) トリプレットの概念を理解しましょう:

Model (モデル): データを提供するデータ モデル。表示されるため、データと動作が含まれており、ドメイン モデルまたは JavaBean コンポーネント (データと動作を含む) と考えることができますが、現在は一般的に ValueObject (データ) とサービス層 (動作) に分離されています。つまり、モデルは、データとビジネスを含むモデル データのクエリやモデル データのステータス更新などの機能を提供します。

ビュー: モデル、通常は表示されるユーザー インターフェイスと顧客が見たいものを表示する責任を負います。

Controller (コントローラー): ユーザーリクエストを受け取り、それを処理 (状態変更) のためにモデルに委任し、処理後に返されたモデルデータをビューに返します。ビューはそれを表示する責任があります。言い換えれば、コントローラーはディスパッチャーの仕事を実行します。

図 1-1 から、標準 MVC では、モデルが更新のためにデータをビューにアクティブにプッシュできることもわかります (オブザーバー設計パターン、モデルにビューを登録し、モデルが更新されたときにビューを自動的に更新します)。 Web 内 Web 開発は要求応答モデルであるため、開発中のモデルをビューにアクティブにプッシュすることはできません (ユーザー インターフェイスをアクティブに更新することはできません)。

それでは、Web 上での MVC がどのようなものかを見てみましょう。これを標準の MVC と区別するために WebMVC と呼びます。

WebMVC の概要

モデル ビュー コントローラーの概念は、標準の MVC の概念と同じです。図 1-3 に示すように、WebMVC の標準アーキテクチャをもう一度見てみましょう。

図 1-3

WebMVC モードでは、モデルはビューにデータをアクティブにプッシュできません。ユーザーがビューを更新したい場合は、別のリクエスト (つまり、リクエスト-レスポンス モデル) を送信する必要があります。

Web サイド開発の開発プロセスについて学び、WebMVC がどのように実装されるかを説明しましょう。なぜ MVC モデルを使用する必要があるのでしょうか。

Web 側の開発履歴

ここでは、図 1-4 に示すように、コア プロセスについて簡単に説明します

図 1-4

CGI: (CommonGatewayInterface) パブリック ゲートウェイ インターフェイス、A Web サーバーで使用される、C または Perl 言語で記述されたスクリプト テクノロジ。Web ユーザーのリクエストを受信して​​処理し、最終的にユーザーへの応答を動的に生成します。ただし、各リクエストは負荷の高いプロセスを生成します。

サーブレット: JavaEE Web コンポーネント技術。Web ユーザーのリクエストを受信して​​処理し、最終的にユーザーへの応答を動的に生成するために使用されます。ただし、各リクエストは 1 つのスレッドのみを生成する (スレッド プールがある) ため、軽量です。また、多くの JavaEE テクノロジ (JDBC など) を利用できます。本質は、Java コードで HTML ストリームを出力することです。ただし、プレゼンテーション ロジック、制御ロジック、およびビジネス ロジックの呼び出しは混在しています。図1-5に示すように

図 1-5

図 1-5 に示すように、このアプローチは、制御ロジック、パフォーマンス コード、およびビジネス ロジック オブジェクトの呼び出しが混在しているため、Java コードで直接 HTML を出力することは絶対に望ましくありません。 , そのため、フロントエンド開発者はページスタイルなどを設計したり変更したりすることができません。変更するだけでも非常に面倒なので、このアプローチは実際のプロジェクトではお勧めできません。

JSP: (JavaServerPage): サーバー側で実行される Web コンポーネントで、標準の HTML ページにスクリプト言語 (現在は Java のみをサポート) を埋め込むテンプレート ページ テクノロジです。本質は、HTML コードに Java コードを埋め込むことです。 JSP は最終的にはサーブレットにコンパイルされますが、純粋なサーブレット ページを開発するよりも簡単で便利です。ただし、プレゼンテーション ロジック、制御ロジック、およびビジネス ロジックの呼び出しは依然として混在しています。図 1-6

図 1-6

図 1-6 に示すように、このアプローチは制御ロジック、パフォーマンス コード、およびビジネス ロジック オブジェクトの呼び出しが混在しているため、まったく望ましくありませんが、より良い方法です。サーブレットを直接呼び出す フロントエンド開発者は単純なページ スタイルを設計および変更できるため (ただし、埋め込まれた Java スクリプトが多すぎる場合は変更が困難です)、このアプローチは実際のプロジェクトではお勧めできません。

JSP の本質はやはりサーブレットですが、最終的には実行時にサーブレット (tomcatworkCatalinaweb アプリケーション名 orgapachejsp で生成される tomcat など) が生成されますが、これにより HTML の記述が簡素化されますが、依然として必要となります。制御ロジック、パフォーマンスコード、ビジネスロジックオブジェクト呼び出しが混在しています。

モデル 1: JSP の拡張バージョンと考えることができ、図 1-7 に示すように jsp+javabean と考えることができます

機能: jsp:useBean 標準アクションを使用して、リクエスト パラメーターを JavaBean コンポーネントに自動的にカプセル化します; 制御ロジックを実行するには Java スクリプトも使用する必要があります。

図 1-7

ここでは、jsp:useBean 標準アクションを使用すると、Javabean の取得/作成が簡素化され、リクエスト パラメーターが Javabean にカプセル化されることがわかります。図に示すように、Model1 アーキテクチャをもう一度見てみましょう。 1～8。

図 1-8 Model1 アーキテクチャ

Model1 アーキテクチャでは、JSP は制御ロジック、プレゼンテーション ロジック、およびビジネス オブジェクト (Javabean) 呼び出しを担当します。純粋な JSP よりも、リクエスト パラメーターの取得とリクエスト パラメーターのカプセル化のみが簡素化されます。また、これは悪質なため、プロジェクトでの使用 (またはせいぜいデモでの使用) を厳しく禁止する必要があります。

Model2: JavaEE の世界では、WebMVC モデルと考えることができます。

Model2 アーキテクチャは、実際には、コントローラーがサーブレットを使用し、モデルが JavaBean を使用し、ビューが使用される点を除いて、いわゆる WebMVC モデルと考えることができます。図 1-9 に示すように、JSP を使用します

図 1-9 Model2 アーキテクチャ

具体的なコード例は次のとおりです。ビューとモデルが分離され、制御ロジックと表示ロジックが分離されていること。

しかし、重大な欠点もあります:

Controller:

1. 実際には、リクエスト パラメーター submitFlag=toAdd などのプロトコルに従うことができます。 2. 制御ロジックを単純化するため、基本的に各モジュールにコントローラーが必要なため、制御ロジックが非常に複雑になる可能性があります。 3. リクエスト パラメーターをモデルにカプセル化するのは面倒です。これを行うためにフレームワークを使用すると、解放されます。

4. 次のビューを選択し、ServletAPI に大きく依存するため、表示されるモデル データを送信することが困難になります。ビューに ServletAPI を使用すると、ビューのテクノロジも同時に変更する必要があり、非常に面倒です。

1 モデル:

ここのモデルは JavaBean を使用しているため、JavaBean コンポーネント クラスが非常に大きくなる可能性があります。現在、プロジェクトでは JavaBean の代わりに 3 層アーキテクチャが使用されています。

Views

は現在 JSP にバインドされており、Velocity や FreeMarker などのビューを変更するのは困難です。たとえば、Excel や PDF ビューなどをサポートしたいと考えています。

ワーカーへのサービス: FrontController+ApplicationController+PageController+Context

つまり、フロントエンド コントローラー + アプリケーション コントローラー + ページ コントローラー (アクションとも呼ばれます) + コンテキスト、これも WebMVC ですが、責任は次のようにより明確です。図 1-10:

図 1-10

実行中のプロセスは次のとおりです:

責任:

FrontController: フロントエンド コントローラー。プレゼンテーション層により、Model2 制御ロジックの重複が回避されます (フロントエンド コントローラーは、submitFlag=login に従ったログイン メソッドの以前の転送など、統一された方法で対応する関数メソッドをコールバックし、複数のロジックに共通のロジックを提供できます)。リクエスト（コンテキストの準備など）と特定のビューの選択と特定の機能処理（ログイン時のモデルへのリクエストパラメータのカプセル化やビジネスロジックオブジェクトの呼び出しなど）は分離されます。

ApplicationController: アプリケーション コントローラー。フロントエンド コントローラーが特定のビューと特定の機能処理を分離して選択した後、アプリケーション コントローラーは特定のビュー テクノロジ (ビュー管理) と特定の機能処理 (ページ コントロール) を選択するために使用されます。 ) 戦略的なデザイン パターンのアプリケーションであるコントローラー/コマンド オブジェクト/アクション管理) は、相互に影響を与えることなくビュー/ページ コントローラーを簡単に切り替えることができます。

PageController(コマンド): ページ コントローラー/アクション/プロセッサー: コード処理関数、パラメーターの収集、モデルへのパラメーターのカプセル化、ビジネス オブジェクト処理モデルの転送、論理ビュー名をフロントエンド コントローラー (および特定のビュー テクノロジー) に返します。説明 カップリング)、フロントエンド コントローラーはアプリケーション コントローラーに委任して、表示する特定のビューの選択を行います。これは、コマンド設計パターンの実装となる場合があります。ページ コントローラーはハンドラーまたはアクションとも呼ばれます。

コンテキスト: コンテキスト。Model2 で覚えています。ビューに表示するモデル データを準備します。それをリクエスト (ServletAPI 関連) に直接入れます。コンテキストを使用すると、関連するデータをコンテキストに配置できます。プロトコルとは関係ありません モデルデータ (ServletAPI など) へのアクセス/設定は、通常、ThreadLocal モードで実装されます。

この時点で、Web 開発アーキテクチャ全体の開発履歴を確認しました。Web レイヤー フレームワークによって詳細は異なる場合がありますが、目的は同じです:

Web プレゼンテーション レイヤーをクリーンにする:

モデルとビューを分離する。 ;

コントローラー内の制御ロジックと機能処理の分離 (モデルオブジェクトとビジネスオブジェクト呼び出しへのパラメーターの収集とカプセル化);

コントローラー内のビュー選択と特定のビューテクノロジーの分離。

薄い Web プレゼンテーション層:

実行することは少ないほど良い、薄いため、無関係なコードを含めるべきではありません

パラメータを収集してモデル オブジェクトに整理し、呼び出しを開始することのみを担当します。ビジネス オブジェクト;

コントローラーは論理ビュー名のみを返し、対応するアプリケーション コントローラーは使用する特定のビュー戦略を選択します。

テストを容易にするために、フレームワーク固有の API の使用を最小限に抑えます。

以上がJava での Web MVC のグラフィカルな紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。