MVC アーキテクチャの概要
すべてのプログラマが知っている最も一般的なアプリケーション アーキテクチャはMVCです。MVC はModel-View-Controllerの略です。
これはアプリケーションのアーキテクチャというよりは、アプリケーション コンポーネントのアーキテクチャですが、このニュアンスについては後ほど説明します。MVCとは何ですか?
MVC は、アプリケーション データと制御ロジックを 3 つの個別のコンポーネント(モデル、ビュー、コントローラー) に分離し、各コンポーネントを個別に変更できるようにするためのスキームです。
- モデル (Model) はデータを提供し、状態を変更することでコントローラーのコマンドに応答します。
- ビューは、モデルの変更に応じてユーザーにモデル データを表示する役割を果たします。
- コントローラー (Controller) はユーザーのアクションを解釈し、変更の必要性をモデルに通知します。
このモデルは1978年（！）に発明されました。はい、適切なソフトウェア アーキテクチャに関する問題は 50 年前にも関連していました。オリジナルの図では、このモデルがどのように説明されているかを次に示します。
このモデルは、データとそれらを操作するためのメソッド (データベースへのクエリ、正確さのチェック) を提供します。モデルはビュー(データのレンダリング方法を知りません) やコントローラー (ユーザー対話ポイントを持たない) から独立しており、データへのアクセスとデータの管理を提供します。
このモデルは、状態を変更することでリクエストに応答する方法で構築されており、「オブザーバー」への通知を組み込むことができます。モデルは視覚的表現から独立しているため、1 つの「モデル」に対して複数の異なる表現を持つことができます。
ビューは、モデルから必要なデータを取得し、それをユーザーに送信する責任があります。ビューはユーザー入力を処理しません。
コントローラーは、ユーザーとシステム間の「通信」を提供します。データを制御し、ユーザーからシステムへ、またはその逆にデータを送信します。モデルとビューを使用して、目的のアクションを実装します。
このモデルが数十年にわたって少しずつ進化してきたという事実には、ある種の困難があります。つまり、名前は同じままですが、部品の目的が変わり始めました。
Web 上の MVC アーキテクチャ
MVC 設計パターンの背後にある考え方は非常にシンプルです。アプリケーション内のさまざまな動作に対する責任を明確に分離する必要があります。
モデル— データ処理とアプリケーション ロジック。
意見— サポートされている形式でデータをユーザーに提供します。
コントローラ- ユーザーリクエストを処理し、適切なリソースを呼び出します。
アプリケーションは 3 つの主要コンポーネントに分割されており、それぞれが異なるタスクを担当します。例を使用して、クライアント/サーバー アプリケーションのコンポーネントを詳しく見てみましょう。
コントローラ
ユーザーがブラウザのページ上のさまざまな要素をクリックすると、ブラウザはさまざまな HTTP リクエスト (GET、POST など) を送信します。コントローラーには、ページ内で動作するブラウザーと JS コードを含めることができます。
この場合のコントローラーの主な機能は、必要なオブジェクトのメソッドを呼び出し、リソースへのアクセスを管理してユーザーが指定したタスクを実行することです。通常、コントローラーはタスクに適切なモデルを呼び出し、適切なビューを選択します。
モデル
広い意味でのモデルとは、データとそのデータを操作するために使用されるルールであり、これらが一緒になってアプリケーションのビジネス ロジックを構成します。アプリケーションの設計は常に、アプリケーションが動作するオブジェクトのモデルを構築することから始まります。
書籍を販売するオンライン ストアがあるとします。その場合、その人は単なるアプリケーション ユーザーなのでしょうか、それとも本の著者でもあるのでしょうか? これらの重要な質問は、モデルの設計時に解決する必要があります。
さらに、何ができるか、何ができないか、どのデータセットが許容され、どのデータセットが許容されないかといった一連のルールがあります。著者なしで本は存在できますか? そして本を持たない著者は？ユーザーの生年月日が西暦 300 年であってもよいかなど。
モデルは、ユーザーが要求したデータ (メッセージ、本のページ、写真など) のビューをコントローラーに提供します。データ モデルは、ユーザーにどのように表示するかに関係なく同じです。したがって、データを表示するために利用可能なビューを選択します。
モデルには、アプリケーション ロジックの最も重要な部分、つまり、扱っている問題 (フォーラム、ショップ、銀行など) を解決するロジックが含まれています。コントローラーには、主にアプリケーション自体の組織ロジックが含まれています (プロジェクト マネージャーと同様)。
意見
ビューは、モデルから受信したデータを表現するさまざまな方法を提供します。データが詰め込まれたテンプレートにすることもできます。いくつかの異なるビューがあり、コントローラーが現在の状況に最適なものを選択します。
Web アプリケーションは通常、コントローラー、モデル、ビューのセットで構成されます。コントローラーはバックエンドにのみ存在できますが、ロジックがフロントエンドにも分散されている場合は、複数のコントローラーのバリアントが存在することもあります。このアプローチの良い例は、あらゆるモバイル アプリケーションです。
Web 上の MVC サンプル
書籍を販売するオンライン ストアを開発する必要があるとします。ユーザーは、本の閲覧、登録、購入、現在の注文へのアイテムの追加、気に入った本にマークを付けて購入するなどのアクションを実行できます。
アプリケーションには、すべてのビジネス ロジックを担当するモデルが必要です。また、すべてのユーザー アクションを処理し、ビジネス ロジックからのメソッド呼び出しに変換するコントローラーも必要です。ただし、1 つのコントローラー メソッドでさまざまなモデル メソッドを呼び出すことができます。
また、一連のビュー (書籍のリスト、1 冊の書籍に関する情報、ショッピング カート、注文のリスト) も必要です。Web アプリケーションの各ページは、実際には、モデルの特定の側面をユーザーに表示する個別のビューです。
ユーザーが書店推奨本のリストを開いてタイトルを表示するとどうなるかを見てみましょう。一連のアクション全体は、6 つのステップの形式で説明できます。
手順:
- ユーザーが「おすすめ」リンクをクリックすると、ブラウザはリクエストを/books/recommendations などに送信します。
- コントローラーはリクエストをチェックします。ユーザーはログインしている必要があります。あるいは、ログインしていないユーザー向けの書籍コレクションを用意する必要があります。次に、コントローラーはモデルを呼び出し、ユーザー N に推奨される本のリストを返すように依頼します。
- モデルはデータベースにアクセスし、そこから書籍に関する情報 (現在人気の本、ユーザーが購入した本、友人が購入した本、欲しいものリストにある本) を取得します。このデータに基づいて、モデルは推奨書籍 10 冊のリストを作成し、コントローラーに返します。
- コントローラーは推奨書籍のリストを受け取り、それを確認します。この段階では、コントローラーが決定を下します。本が少ない場合、またはリストが完全に空の場合は、ログインしていないユーザーの本のリストを要求します。現在プロモーションが行われている場合、管理者はプロモーションの書籍をリストに追加できます。
- コントローラーはユーザーにどのページを表示するかを決定します。それは、エラー ページ、書籍のリストを含むページ、ユーザーが 100 万人目の訪問者になったことを祝うページなどです。
- サーバーは、コントローラーによって選択されたページ ( view ) をクライアントに提供します。これには必要なデータ (ユーザー名、本のリスト) が書き込まれ、クライアントに送信されます。
- クライアントはページを受信し、ユーザーに表示します。
このアプローチの利点は何ですか?
MVC 概念を使用することで得られる最も明白な利点は、プレゼンテーション ロジック (ユーザー インターフェイス) とアプリケーション ロジック (バックエンド) が明確に分離されていることです。
2 番目の利点は、サーバー部分がスマート モデル (実行者) とコントローラー (意思決定センター) の 2 つに分割されていることです。
前の例では、コントローラーがモデルから推奨書籍の空のリストを受け取り、それをどう扱うかを決定できる瞬間がありました。理論的には、このロジックをモデルに直接組み込むことができます。
まず、おすすめの本をリクエストするときに、リストが空の場合にどうするかをモデルが決定します。次に、同じ場所にコードを追加し、現在プロモーションが行われている場合はどうするか、さらにさまざまなオプションを追加する必要があります。
その後、ストア管理者はプロモーションなしでユーザーのページがどのように表示されるかを確認したい、またはその逆、現在プロモーションはありませんが、将来のプロモーションがどのように表示されるかを確認したいことがわかりました。そしてこれには方法がありません。したがって、意思決定センター (コントローラー) をビジネス ロジック (モデル) から分離することが決定されました。
MVC の概念は、ビューをアプリケーション ロジックから分離することに加えて、大規模なアプリケーションの複雑さを大幅に軽減します。コードはより構造化されているため、ソリューションの保守、テスト、再利用が容易になります。
MVC の概念を理解すると、開発者として、書籍リストの並べ替えをどこに追加する必要があるかがわかります。
- データベースクエリレベル。
- ビジネス ロジック (モデル) のレベル。
- ビジネス ロジック レベル (コントローラー)。
- ビュー内 - クライアント側。
そして、これは修辞的な質問ではありません。ここで、本のリストを並べ替えるためのコードをどこに、なぜ追加する必要があるかを考えてください。
クラシック MVC モデル
MVC コンポーネント間の対話は、Web アプリケーションとモバイル アプリケーションでは異なる方法で実装されます。これは、Web アプリは存続時間が短く、1 つのユーザー リクエストを処理して終了するのに対し、モバイル アプリは再起動せずに多くのリクエストを処理するためです。
通常、Web アプリケーションは「パッシブ」モデルを使用しますが、モバイル アプリケーションは「アクティブ」モデルを使用します。パッシブ モデルとは異なり、アクティブ モデルでは、サブスクライブして変更の通知を受け取ることができます。これは Web アプリケーションには必要ありません。
さまざまなモデルのコンポーネントの相互作用は次のようになります。
モバイル アプリケーション (アクティブ モデル) は、イベントとイベント サブスクリプション メカニズムをアクティブに使用します。このアプローチでは、ビュー ( view ) はモデルの変更をサブスクライブします。その後、何らかのイベントが発生すると (ユーザーがボタンをクリックするなど)、コントローラーが呼び出されます。また、モデルにデータを変更するコマンドを与えます。
一部のデータが変更された場合、モデルはこのデータの変更に関するイベントを生成します。このイベントをサブスクライブしたすべてのビュー (この特定のデータを変更することが重要です) は、このイベントを受信し、インターフェース内のデータを更新します。
Web アプリケーションでは、構成が少し異なります。主な技術的な違いは、クライアントがサーバーの主導でサーバー側のメッセージを受信できないことです。
したがって、Web アプリケーションのコントローラーは通常、ビューにメッセージを送信しませんが、クライアントに新しいページを提供します。これは技術的には新しいビュー、または新しいクライアント アプリケーションです (一方のページがもう一方のページについて何も知らない場合)。 。
現時点では、この問題は次のアプローチを使用して部分的に解決されています。
- 重要なデータに変更がないかサーバーを定期的にポーリングします (1 分に 1 回以上)。
- WebSocket を使用すると、クライアントはサーバー メッセージをサブスクライブできます。
- サーバー側からの Web プッシュ通知。
- HTTP/2 プロトコルを使用すると、サーバーはクライアントへのメッセージの送信を開始できます。