MVCの正式名称はModel View Controllerといい、Model（モデル）-View（ビュー）-Controller（コントローラー）の略であり、ソフトウェア設計のモデルの一つです。ビジネスロジック、データ、インターフェース表示を分離してコードを整理する手法を採用しており、多くのビジネスロジックを1つのコンポーネントにまとめており、インターフェースやユーザーインタラクションの改善やカスタマイズが必要な場合でも、ビジネスロジックを書き直す必要がありません。 . 、エンコード時間を短縮します。
MVC はもともとデスクトップ プログラムに存在し、M はビジネス モデル、V はユーザー インターフェイス、C はコントローラーを指します。
使用される MVC の目的は、M と V の実装コードを分離し、同じプログラムで異なる表現形式を使用できるようにすることです。例えば、Windowsのシステムリソースマネージャーのフォルダー内容の表示モードですが、以下の2つの図の左側が詳細情報表示モード、右側が中アイコン表示モードとなっており、ファイルの内容は表示されていません。変更されましたが、表示モードが変更されました。ユーザーがどのような表示モードを使用しても、ファイルの内容は変化せず、M と V を分離する目的は達成されます。
ウェブページでは、
V はビューです。ビューは、ユーザーが表示して操作するインターフェイスを指します。たとえば、HTML 要素で構成される Web ページ インターフェイスやソフトウェア クライアント インターフェイスなどです。MVC の利点の 1 つは、アプリケーションのさまざまなビューを処理できることです。ビューでは実際の処理は行われません。これは、データを出力し、ユーザーがそれを操作できるようにする単なる方法です。
M はモデルmodel であり、モデルがビジネス ルールを表現していることを意味します。MVC の 3 つのコンポーネントのうち、モデルには最も多くの処理タスクがあります。モデルによって返されるデータは中立であり、モデルはデータ形式とは何の関係もありません。このようなモデルは複数のビューにデータを提供できます。モデルに適用されたコードは複数のビューで再利用できるため、コードの重複が減少します。セックス。
C はコントローラーです コントローラーとは、コントローラーがユーザーの入力を受け入れ、ユーザーのニーズを完了するためにモデルとビューを呼び出すことを意味します。コントローラー自体は何も出力したり、処理を実行したりしません。リクエストを受信し、リクエストを処理するためにどのモデル コンポーネントを呼び出すかを決定し、返されたデータを表示するためにどのビューを使用するかを決定するだけです。
以下の図は、3 つの間の呼び出し関係を示しています。
ユーザーは最初にインターフェイスで人間とコンピューターの対話を実行し、次にコントローラーにリクエストを送信し、コントローラーはリクエストのタイプと要求された命令に従ってそれを対応するモデルに送信し、ロジックは表示する対応するビューを選択します。今回、ユーザーはこのインタラクションのフィードバック情報を取得し、次のインタラクションを実行できるようになります。
MVC の例 1:
最も典型的な MVC は、jsp+servlet+javabean モードです。
JavaBean は、モデルとして、ビジネス データをカプセル化するデータ モデルとして使用でき、また、アプリケーションのビジネス操作を含めるためのビジネス ロジック モデルとしても使用できます。このうち、データモデルはビジネスデータの保存や送信に使用され、ビジネスロジックモデルはコントローラーからのモデル更新要求を受信した後に特定のビジネスロジック処理を実行し、対応する実行結果を返します。
プレゼンテーション層として、JSP はユーザーにデータを表示するページを提供し、ユーザーのリクエストに対応するフォーム (Form) を提供し、適切なタイミング (ボタンのクリック) でコントローラーにリクエストを送信してモデルの更新をリクエストする役割を果たします。
Serlvet はコントローラーとして、ユーザーが送信したリクエストを受信し、リクエスト内のデータを取得してビジネス モデルに必要なデータ モデルに変換し、ビジネス モデルの対応するビジネス メソッドを呼び出して更新します。 、同時に業務実行結果に応じて必要なデータを選択するビューが返されます。
MVC の例 2:
Struts2 フレームワーク: Struts2 は、MVC に基づく軽量の Web アプリケーション フレームワークです。Struts2 の適用範囲は Web アプリケーションであり、Web アプリケーションの分野における日常業務と一般的な問題の抽象化に焦点を当て、Web アプリケーション開発を迅速に完了するのに役立つプラットフォームを提供します。Struts2 をベースに開発された Web アプリケーションは当然 MVC を実現できますが、Struts2 は MVC のさまざまな部分で開発を支援することに重点を置いています。
コードを通して簡単に説明しましょう。
ログイン.html
ログイン.java
Struts.xml
ユーザーはまず、Login.html にユーザー名とパスワードを入力し、クリックしてログインします。このとき、アクションのパスに従って、struts.xml で対応する Login を見つけて、次に従って対応する login.Java を入力します。対応するクラスのパス ここで判定した後、成功またはエラーを返し、struts.xmlの結果値に従って、対応するjspページをポイントします。
コントローラー - フィルターディスパッチャー
上の図から、ユーザー リクエストは最初にフロント コントローラー FilterDispatcher に到達します。FilterDispatcher は、ユーザーが送信した URL と struts.xml 内の構成に従って適切なアクション (Action) を選択し、このアクションでユーザーのリクエストを処理します。FilterDispatcher は実際にはフィルター (サーブレット仕様の Web コンポーネントである Filter) であり、Struts2 コア パッケージの既成クラスです。開発する必要はなく、プロジェクトの web.xml で構成するだけです。FilterDispatcher は、J2EE コア設計パターンのフロント コントローラー パターンを具体化します。
アクション - アクション
ユーザーリクエストは FilterDispatcher を通過した後、適切な Action オブジェクトに配布されます。アクションは、ユーザー リクエスト内のパラメーターを適切なデータ モデルに組み立て、実際の関数処理に対応するビジネス ロジックを呼び出し、次のビュー表示に必要なデータを取得する責任を負います。Struts2のアクションは他のWebフレームワークのアクション処理と比較してサーブレットAPIとの切り離しが実現されており、アクション内でHttpServletRequestやHttpServletResponseなどのインターフェースを直接参照して使用する必要がありません。したがって、Action の単体テストはより簡単になり、強力な型変換により、反復作業が大幅に減ります。
Visual Studio で新しい ASP.NET MVC Web アプリケーションを作成します。
作成が完了すると、作成されたプロジェクトにはコントローラー、モデル、ビューが含まれ、MVC のプログラミングのアイデアを具体化します。
ビュー層はビジネス層から分離されているため、モデルとコントローラーのコードを再コンパイルせずにビュー層のコードを変更できます。同様に、アプリケーションのビジネス プロセスまたはビジネス ルールを変更する場合も、MVC モデル層を変更するだけで済みます。モデルがコントローラーやビューから分離されているため、アプリケーションのデータ層やビジネスルールを簡単に変更できます。
2. 高い再利用性
MVCパターンでは、さまざまなスタイルのビューを使用して同じサーバー側コードにアクセスできます。これは、複数のビューが WEB (HTTP) ブラウザーやワイヤレス ブラウザー (wap) を含むモデルを共有できるためです。たとえば、ユーザーはパソコンからのご注文 携帯電話からのご注文も可能です ご注文方法は異なりますが、ご注文いただいた商品の処理方法は同じです。モデルから返されるデータはフォーマットされていないため、同じウィジェットを異なるインターフェイスで使用できます。
3. 迅速な導入と低いライフサイクルコスト
MVC は、ユーザーインターフェイスの開発と保守の技術的な内容を軽減します。MVC モードを使用すると、開発時間を大幅に短縮でき、プログラマ (Java 開発者) はビジネス ロジックに集中し、インターフェイス プログラマ (HTML および JSP 開発者) はプレゼンテーションに集中できます。
4. 高いメンテナンス性
ビュー層とビジネスロジック層を分離することで、WEB アプリケーションの保守と変更も容易になります。
MVC の欠点:
1. MVC を完全に理解することはさらに複雑です。
MVC モデルが提案されてから長く経っておらず、学生の実践経験も不足しているため、MVC を完全に理解し、習得するのは簡単ではありません。
2. デバッグが難しい。
モデルとビューは厳密に分離する必要があるため、アプリケーションのデバッグが困難になり、各コンポーネントを使用する前に徹底的にテストする必要があります。
3. 小規模、中規模のアプリケーションには適していません
中小規模のアプリケーションでは、開発に MVC の使用を必須にすると、多くの場合時間がかかり、MVC の利点が反映されず、開発が煩雑になります。
4. システムの構造と実装の複雑さの増加
シンプルなインターフェイスの場合、MVC に厳密に従ってモデル、ビュー、コントローラーを分離すると、構造が複雑になり、更新操作が過剰に発生して操作効率が低下する可能性があります。
5. ビューとコントローラー間の接続が強すぎるため、ビューからモデル データへのアクセスが減少します。
ビューとコントローラーは互いに分離されていますが、密接に関連するコンポーネントです。ビューにはコントローラーがないため、その用途は非常に限定されており、またその逆も同様であり、そのため独立して再利用することができません。