パート 7. MVC (Model-View-Controller) パターンの紹介

この資料は「エンタープライズ開発入門」シリーズの一部です。以前の記事:

• ネットワーキングについて
• ソフトウェアアーキテクチャについて
• HTTP/HTTPSについて
• Maven の基本について
• サーブレットについて (簡単な Web アプリケーションの作成)
• サーブレットコンテナについて

この記事では、MVC と呼ばれるものについて学びます。MVC とは何かについて説明し、その歴史に触れ、MVC で具体化される基本的なアイデアと概念を探り、アプリケーションをモデル、ビュー、コントローラー モジュールに分割する方法を段階的に見ていき、 Spring Boot を使用した小規模な Web アプリケーションを確認し、例として Spring MVC を使用して、データが Java コードから HTML ページにどのように送信されるかを確認します。このマテリアルを理解するには、デザイン パターン、特にオブザーバーとファサードに精通している必要があります。また、HTTP リクエストとレスポンスに精通し、HTML の基本を理解し、Java アノテーションとは何かを理解してください。コーヒーとスナックを飲みながら、快適にお過ごしください。さぁ、始めよう。

MVCの歴史

MVC の背後にあるアイデアは、1970 年代後半に Xerox PARC で働いていた Trygve Reenskaug によって策定されました。当時、コンピュータを扱うには学位が必要であり、膨大な文書を継続的に研究する必要がありました。Reenskaug が非常に強力な開発者のグループと協力して解決した課題は、一般ユーザーのコンピューターとの対話を簡素化することでした。非常にシンプルで理解しやすい一方で、コンピューターや複雑なアプリケーションの制御を可能にするツールを作成する必要がありました。リースカウグは、アラン・ケイの指導の下、「あらゆる年齢の子供向け」ラップトップ・コンピューター、ダイナブックとスモールトーク言語を開発するチームに取り組みました。このとき、フレンドリーなインターフェイスの概念が定められました。多くの点で、Reenskaug と彼のチームが行った研究は、IT 分野の進化に影響を与えました。MVC には直接当てはまりませんが、これらの開発の重要性を示す興味深い事実を次に示します。アラン・ケイ言った「私が初めて Apple 社に来たとき、それは 84 年でした。Mac はすでに世に出ていましたが、ニューズウィーク誌から連絡があり、Mac についてどう思うか尋ねられました。私はこう言いました。『そうですね、Mac は、批判されるだろう』それで、2007 年に iPhone を発表した後、彼はそれを私のところに持ってきて手渡し、「アラン、これは批判されるほど良いことですか？」と言いました。そして私は言いました、「スティーブ、これをタブレットと同じくらいの大きさにすれば、あなたは世界を支配できるでしょう。」 3 年後の 2010 年 1 月 27 日、Apple は対角 9.7 インチの iPad を発表しました。言い換えれば、スティーブ・ジョブズはアラン・ケイのアドバイスをほぼ正確に従ったということになる。リースカウグのプロジェクトは 10 年間続きました。しかし、MVC に関する最初の出版物はさらに 10 年後に世に出ました。Martin Fowler 氏、ソフトウェア アーキテクチャに関するいくつかの書籍や記事の著者、彼は、Smalltalk の実用バージョンを使用して MVC を研究したと述べています。長い間、オリジナルの情報源から MVC に関する情報がなかったため、また他のいくつかの理由により、この概念については多数の異なる解釈が現れました。その結果、多くの人が MVC をデザイン パターンであると考えています。あまり一般的ではありませんが、MVC は複合パターン、または連携して複雑なアプリケーションを作成する複数のパターンの組み合わせと呼ばれます。しかし、前述したように、MVC は実際には主に、異なるパターンを使用してさまざまな方法で実装できる一連のアーキテクチャ上のアイデア/原則/アプローチです。次に、MVC の概念に組み込まれている主なアイデアについて検討します。そして他のいくつかの理由から、この概念については多数の異なる解釈が現れました。その結果、多くの人が MVC をデザイン パターンであると考えています。あまり一般的ではありませんが、MVC は複合パターン、または連携して複雑なアプリケーションを作成する複数のパターンの組み合わせと呼ばれます。しかし、前述したように、MVC は実際には主に、異なるパターンを使用してさまざまな方法で実装できる一連のアーキテクチャ上のアイデア/原則/アプローチです。次に、MVC の概念に組み込まれている主なアイデアについて検討します。そして他のいくつかの理由から、この概念については多数の異なる解釈が現れました。その結果、多くの人が MVC をデザイン パターンであると考えています。あまり一般的ではありませんが、MVC は複合パターン、または連携して複雑なアプリケーションを作成する複数のパターンの組み合わせと呼ばれます。しかし、前述したように、MVC は実際には主に、異なるパターンを使用してさまざまな方法で実装できる一連のアーキテクチャ上のアイデア/原則/アプローチです。次に、MVC の概念に組み込まれている主なアイデアについて検討します。

MVC: 基本的な考え方と原則

• VC は、ユーザー インターフェイスを備えた複雑な情報システムを構築するための一連のアーキテクチャ上のアイデアと原則です
• MVC は、Model-View-Controller の略語です。

免責事項: MVC はデザイン パターンではありません。MVC は、ユーザー インターフェイスを備えた複雑なシステムを構築するための一連のアーキテクチャ上のアイデアと原則です。ただし、便宜上、「一連のアーキテクチャ上のアイデア...」と繰り返し言わないように、MVC パターンを参照します。簡単なことから始めましょう。Model-View-Controllerという言葉の裏には何が隠されているのでしょうか？MVC パターンを使用してユーザー インターフェイスを備えたシステムを開発する場合、システムを 3 つのコンポーネントに分割する必要があります。モジュールまたはコンポーネントと呼ぶこともできます。呼び方は自由ですが、システムを 3 つのコンポーネントに分割します。各コンポーネントには独自の目的があります。 モデル。最初のコンポーネント/モジュールはモデルと呼ばれます。これには、アプリケーションのすべてのビジネス ロジックが含まれています。 意見。システムの 2 番目の部分はビューです。このモジュールは、ユーザーにデータを表示する役割を果たします。ユーザーが見るものはすべてビューによって生成されます。 コントローラ。このチェーンの 3 番目のリンクはコントローラーです。これには、ユーザー アクションの処理を担当するコードが含まれています (すべてのユーザー アクションはコントローラーで処理されます)。モデルはシステムの最も独立した部分です。非常に独立しているため、ビューとコントローラー モジュールについて何も認識する必要はありません。モデルは非常に独立しているため、開発者はビューとコントローラーについて事実上何も知らない可能性があります。ビューの主な目的は、ユーザーが利用できる形式でモデルからの情報を提供することです。ビューの主な制限は、いかなる方法でもモデルを変更してはいけないことです。コントローラーの主な目的は、ユーザーのアクションを処理することです。ユーザーはコントローラーを介してモデルに変更を加えます。より正確には、モデルに保存されているデータに対してです。これは、レッスンで以前に見た図です。 これらすべてから、論理的な結論を導き出すことができます。複雑なシステムはモジュールに分割する必要があります。この分離を達成するための手順を簡単に説明しましょう。

ステップ 1. アプリケーションのビジネス ロジックをユーザー インターフェイスから分離する

MVC の主な考え方は、ユーザー インターフェイスを持つアプリケーションは 2 つのモジュールに分割できるということです。ビジネス ロジックの実装を担当するモジュールとユーザー インターフェイスです。最初のモジュールはアプリケーションの主な機能を実装します。このモジュールはシステムの中核であり、アプリケーションのドメイン モデルが実装されます。MVC パラダイムでは、このモジュールは文字 M、つまりモデルです。2 番目のモジュールは、ユーザーにデータを表示し、ユーザーとアプリケーションの対話を処理するロジックを含む、ユーザー インターフェイス全体を実装します。この分離の主な目的は、システムのコア (MVC 用語では「モデル」) を独立して開発およびテストできるようにすることです。この分離を行った後のアプリケーションのアーキテクチャは次のようになります。

ステップ 2 オブザーバー パターンを使用してモデルの独立性をさらに高め、ユーザー インターフェイスを同期します

ここには 2 つの目標があります。

1. モデルのさらなる独立性を実現
2. ユーザーインターフェースを同期する

次の例は、ユーザー インターフェイスの同期の意味を理解するのに役立ちます。オンラインで映画のチケットを購入し、劇場の空席数を確認するとします。同時に、他の誰かが映画のチケットを購入している可能性があります。この他の人が私たちより先にチケットを購入した場合、私たちが検討しているショータイムに利用できる座席の数が減少することを望みます。次に、これをプログラム内でどのように実装できるかを考えてみましょう。システムのコア (モデル) とインターフェイス (チケットを購入するための Web ページ) があるとします。2 人のユーザーが同時に劇場の座席を選択しようとしています。最初のユーザーがチケットを購入します。Web ページは、これが起こったことを 2 番目のユーザーに示す必要があります。どうしてこんなことが起こるのでしょうか？インターフェイスをコアから更新すると、その場合、コア (私たちのモデル) はインターフェイスに依存します。モデルを開発してテストするときは、インターフェイスを更新するさまざまな方法を念頭に置く必要があります。これを実現するには、オブザーバー パターンを実装する必要があります。このパターンにより、モデルはすべてのリスナーに変更通知を送信できます。イベント リスナー (またはオブザーバー) として、ユーザー インターフェイスは通知を受信し、更新されます。一方では、オブザーバー パターンを使用すると、実際には何も知らなくても、変更が発生したことをモデルがインターフェイス (ビューとコントローラー) に通知できるため、独立性が保たれます。一方で、ユーザーインターフェイスの同期が可能になります。オブザーバーパターンを実装する必要があります。このパターンにより、モデルはすべてのリスナーに変更通知を送信できます。イベント リスナー (またはオブザーバー) として、ユーザー インターフェイスは通知を受信し、更新されます。一方では、オブザーバー パターンを使用すると、実際には何も知らなくても、変更が発生したことをモデルがインターフェイス (ビューとコントローラー) に通知できるため、独立性が保たれます。一方で、ユーザーインターフェイスの同期が可能になります。オブザーバーパターンを実装する必要があります。このパターンにより、モデルはすべてのリスナーに変更通知を送信できます。イベント リスナー (またはオブザーバー) として、ユーザー インターフェイスは通知を受信し、更新されます。一方では、オブザーバー パターンを使用すると、実際には何も知らなくても、変更が発生したことをモデルがインターフェイス (ビューとコントローラー) に通知できるため、独立性が保たれます。一方で、ユーザーインターフェイスの同期が可能になります。

ステップ 3 インターフェイスをビューとコントローラーに分離する

引き続きアプリケーションをモジュールに分割しますが、今度は階層の下位レベルになります。このステップでは、ユーザー インターフェイス (ステップ 1 で個別のモジュールに分割した) がビューとコントローラーに分割されます。ビューとコントローラーの間に厳密な線を引くのは困難です。ビューはユーザーが見るものであり、コントローラーはユーザーがシステムと対話できるようにするメカニズムであると言うと、矛盾を指摘されるかもしれません。Web ページ上のボタンや電話画面上の仮想キーボードなどのコントロール要素は、基本的にコントローラーの一部です。ただし、これらはビューの他の部分と同じようにユーザーに表示されます。ここで本当に話しているのは、機能の分離です。ユーザー インターフェイスの主な役割は、ユーザーとシステムの対話を容易にすることです。

• システム情報を出力し、ユーザーに便利に表示します
• ユーザーデータとコマンドを入力します（それらをシステムに伝達します）。

これらの関数は、ユーザー インターフェイスをモジュールに分割する方法を決定します。最終的に、システム アーキテクチャは次のようになります。 こうして、モデル、ビュー、コントローラーと呼ばれる 3 つのモジュールで構成されるアプリケーションに到達します。要約しましょう:

1. MVC パラダイムの原則によれば、システムはモジュールに分割する必要があります。
2. 最も重要で独立したモジュールはモデルである必要があります。
3. モデルはシステムの中核です。ユーザー インターフェイスから独立して開発およびテストできる必要があります。
4. これを達成するには、分割の最初のステップで、システムをモデルとユーザー インターフェイスに分割する必要があります。
5. 次に、オブザーバー パターンを使用して、モデルの独立性を強化し、ユーザー インターフェイスを同期します。
6. 3 番目のステップは、ユーザー インターフェイスをコントローラーとビューに分割することです。
7. ユーザー データをシステムに受信するために必要なものはすべてコントローラーにあります。
8. ユーザーに情報を配信するために必要なものはすべてビュー内にあります。

ホットチョコレートを飲む前に、話し合うべき重要なことがもう 1 つあります。

ビューとコントローラーがモデルとどのように対話するかについて少し説明します。

ユーザーはコントローラーから情報を入力することで機種変更を行います。少なくとも、ユーザーはモデル データを変更します。ユーザーがインターフェイス要素を通じて (ビュー経由で) 情報を受け取るとき、ユーザーはモデルに関する情報を受け取っていることになります。これはどうして起こるのでしょうか? ビューとコントローラーはどのような手段でモデルと対話しますか? 結局のところ、ビューのクラスはモデルのクラスのメソッドを直接呼び出してデータを読み書きすることはできません。そうでなければ、モデルが独立しているとは言えません。モデルは、ビューもコントローラーもアクセスすべきではない、密接に関連したクラスのセットです。モデルをビューとコントローラーに接続するには、ファサード デザイン パターンを実装する必要があります。モデルのファサードは、モデルとユーザー インターフェイスの間の層です。これを通じて、ビューは適切にフォーマットされたデータを受け取り、コントローラーはファサードで必要なメソッドを呼び出してデータを変更します。最終的に、すべては次のようになります。

MVC: 何が得られるのでしょうか?

MVC パラダイムの主な目的は、ビジネス ロジックの実装 (モデル) をその視覚化 (ビュー) から分離することです。この分離により、コードの再利用の可能性が高まります。MVC の利点は、同じデータを異なる形式で表示する必要がある場合に最も顕著になります。たとえば、表、グラフ、チャートなど (さまざまなビューを使用)。同時に、ビューの実装方法に影響を与えることなく、ユーザーのアクション (ボタンのクリック、データ入力) への応答方法を変更できます。MVC の原則に従えば、ソフトウェア開発を簡素化し、コードの可読性を高め、拡張性と保守性を向上させることができます。「エンタープライズ開発入門」シリーズの最後の記事では、Spring MVC を使用して構築された MVC 実装について説明します。 パート 8. Spring Boot を使用して小さなアプリケーションを書いてみましょう