MVCフレームワーク

MVCはModel View Controllerの略で、モデル・ビュー・コントローラの略語です。これは広く適用されているソフトウェア設計パラダイムです。その中心となる考え方は、ビジネスロジック、データ、インターフェース表示を分離してコードを整理し、ビジネスロジックを1つのコンポーネントに集中させることです。このようにすることで、インターフェースとユーザーインタラクションを改善およびカスタマイズする際に、ビジネスロジックを書き換える必要はありません。MVCは、従来の入力、処理、出力機能を論理的なグラフィカルユーザーインターフェース構造にマッピングするように独自に開発されました。

MVCプログラミングパターン

MVCは、MVC（モデル・ビュー・コントローラ）設計を使用してWebアプリケーションを作成するためのパターンです。具体的な紹介は以下のとおりです。

+-------------------+
|       Model       |
| アプリケーションの核、例えばデータベースなど | 
| データロジックの処理と          |
| データへのアクセスと保存を担当 | 
+-------------------+
          |
          | データを提供する
          ▼
+-------------------+
|       View        |
| 表示効果、例えばHTMLページなど   |
| モデルデータに基づいて表示コンテンツを作成            |
+-------------------+
          |
          | ユーザーインタラクション
          ▲
+-------------------+
|     Controller    |
| ビジネスロジックを含む入力を処理し、  |
| ビューからデータを読み取り、       |
| ユーザー入力を制御し、        |
| モデルにデータを送信する責任があります  |
+-------------------+

Model: データベースなど、アプリケーションの核を表します。主にアプリケーションのデータロジックの処理を担当します。通常、モデルオブジェクトは、データベース内のデータへのアクセスと保存のタスクを引き受けます。
View: 一般的なHTMLページなど、表示効果に使用されます。ビューは一般にモデルデータに基づいて作成されます。
Controller: ユーザーインタラクションを処理し、通常はビューからデータを読み取り、ユーザー入力を制御し、モデルにデータを送信する責任があります。

MVCパターンは、HTML、CSS、およびJavaScriptに対する完全な制御も提供します。

利点

疎結合: ビュー層とビジネス層が分離されているため、ビュー層のコードを変更するときに、モデルとコントローラーのコードを再コンパイルする必要はありません。同様に、アプリケーションのビジネスプロセスまたはビジネスルールが変更された場合、MVCのモデル層のみを変更する必要があります。モデルがコントローラーとビューから分離されているため、アプリケーションのデータ層とビジネスルールを簡単に調整できます。たとえば、データベースをMySQLからOracleに移行する場合、またはRDBMSデータソースからLDAPに変更する場合は、モデル部分のみを変更する必要があります。モデルが正しく実装されていれば、データソースがデータベースであろうとLDAPサーバーであろうと、ビューは対応するデータを正しく表示できます。MVCアプリケーションの3つのコンポーネントは互いに独立しているため、いずれかを変更しても他の2つには影響しません。したがって、疎結合システムは、この設計思想に基づいて構築できます。
高い再利用性: テクノロジーの発展に伴い、アプリケーションに複数の方法でアクセスする必要があります。MVCパターンを使用すると、さまざまなスタイルのビューが同じサーバー側コードにアクセスできます。複数のビューが1つのモデルを共有できるため、WEB（HTTP）ブラウザーまたはワイヤレスブラウザー（wap）を含みます。たとえば、ユーザーはコンピューターまたは携帯電話から特定の製品を注文できます。注文方法が異なっても、製品注文を処理するためのビジネスロジックは同じです。モデルによって返されるデータはフォーマットされていないため、同じコンポーネントを異なるインターフェースで使用できます。たとえば、多くのデータがHTMLで表現される場合もあれば、WAPで表現される場合もあります。これらの異なる表現を実現するために必要な操作は、ビュー層の実装方法を変更するだけであり、制御層とモデル層をまったく変更する必要はありません。データとビジネスルールがプレゼンテーション層から分離されているため、コードを最大限に再利用できます。モデルには、状態管理およびデータ永続性処理の機能もあります。たとえば、セッションベースのショッピングカートとeコマースプロセスは、Flash Webサイトまたはワイヤレスネットワーク接続アプリケーションでも再利用できます。
低いライフサイクルコスト: MVCは、ユーザーインターフェースの開発と保守の技術的な内容を削減します。
迅速なデプロイ: MVCパターンを使用すると、開発時間が大幅に短縮されます。これにより、プログラマー（Java開発者）はビジネスロジックに集中でき、インターフェースプログラマー（HTMLおよびJSP開発者）はプレゼンテーションに集中できます。
高い保守性: ビュー層とビジネスロジック層を分離することで、Webアプリケーションの保守と変更も容易になります。
ソフトウェアエンジニアリング管理に有利: 異なる層がそれぞれの機能を実行するため、各層の異なるアプリケーションには特定の共通特性があり、エンジニアリングおよびツールを通じてプログラムコードを管理するのに役立ちます。コントローラーは、ユーザーの要件を満たすために異なるモデルとビューを接続するために使用できるという利点も提供します。このように、コントローラーはアプリケーションを構築するための強力な手段を提供できます。いくつかの再利用可能なモデルとビューが与えられた場合、コントローラーはユーザーの要件に応じて処理するモデルを選択し、処理結果をユーザーに表示するビューを選択できます。

欠点

明確な定義がない: MVCを完全に理解するのは簡単ではありません。MVCを使用するには、慎重な計画が必要です。その内部原則は比較的複雑であるため、それについて考えるには時間がかかります。同時に、モデルとビューの厳密な分離により、アプリケーションのデバッグにある程度の困難が生じます。各コンポーネントは、使用する前に十分にテストする必要があります。
中小規模のアプリケーションには適していません: あまり大きくないアプリケーションにMVCを適用するために多くの時間を費やすことは、多くの場合、努力する価値がありません。
システム構造と実装の複雑さが増加する: 単純なインターフェースの場合、MVCに厳密に従い、モデル、ビュー、コントローラーを分離すると、構造の複雑さが増し、更新操作が多すぎるため、動作効率が低下する可能性があります。
ビューとコントローラー間の接続が密すぎる: ビューとコントローラーは、分離されていますが、密接に関連するコンポーネントです。コントローラーが存在しなければ、ビューのアプリケーションは非常に制限されており、その逆も同様です。これは、それらの独立した再利用を妨げます。
ビューによるモデルデータへの非効率的なアクセス: モデルの操作インターフェースに応じて、ビューが十分な表示データを取得するには、複数回呼び出す必要がある場合があります。変更されていないデータへの不要な頻繁なアクセスも、操作パフォーマンスを損ないます。
一般的な高度なインターフェースツールまたはコンストラクターは、パターンをサポートしていません: これらのツールをMVCに適応させ、個別のコンポーネントを確立するためのコストは高いため、MVCの使用が困難になります。

MVPパターン

フルネーム：Model-View-Presenter。MVPは、従来のMVCパターンから進化しました。それらの基本的な考え方は似ており、Controller/Presenterが論理処理を担当し、Modelがデータを提供し、Viewが表示を担当します。

+-------------------+
|       Model       |
|   データを提供し、          |
| データ関連ロジックの処理を担当           |
+-------------------+
          |
          | データを提供する
          ▼
+-------------------+
|       View        |
| データ表示、ユーザーインターフェース parte   |
+-------------------+
          |
          | ユーザーインタラクション
          ▲
+-------------------+
|     Presenter     |
| ロジックの処理、モデル間の相互作用   |
|  ビュー、およびデータフローの調整       |
+-------------------+

利点

モデルとビューの完全な分離: モデルに影響を与えずにビューを変更できます。
モデルのより効率的な使用: すべてのインタラクションが1つの場所、つまりPresenter内部で発生するためです。
高い再利用性: Presenterのロジックを変更せずに、複数のビューに1つのPresenterを使用できます。この機能は、モデルよりもビューの方が頻繁に変更されるため、非常に役立ちます。
テストしやすい: ロジックをPresenterに配置すると、ユーザーインターフェースなしでこれらのロジック（単体テスト）をテストできます。

欠点

ビューのレンダリングはPresenterに配置されるため、ビューとPresenter間のインタラクションが頻繁すぎます。また、Presenterがビューをレンダリングしすぎると、特定のビューとの接続が非常に密接になることがよくあることを理解する必要があります。ビューを変更する必要がある場合は、Presenterも変更する必要があります。たとえば、Presenterが元々Htmlを表示するために使用されていたのが、Pdfも表示する必要がある場合、ビューも変更する必要がある可能性があります。

MVPとMVCの違い

新しいパターンとして、MVPはMVCとは大きく異なります。MVPでは、ViewはModelを直接使用しません。それらの間の通信はPresenter（MVCのController）を介して実行され、すべてのインタラクションはPresenter内部で発生します。MVCでは、ViewはControllerを介さずにModelから直接データを読み取ります。

MVCでは、ViewはModelに直接アクセスできます。その結果、Viewにはモデル情報と必然的にいくつかのビジネスロジックが含まれます。MVCモデルでは、モデルの変更、およびモデルの複数の異なる表示、つまりViewに重点が置かれています。したがって、MVCモデルでは、ModelはViewに依存しませんが、ViewはModelに依存します。さらに、いくつかのビジネスロジックがViewに実装されているため、Viewの変更がより困難になり、少なくともそれらのビジネスロジックは再利用できません。

MVCのViewは確かにModelに「アクセス」できますが、ViewでModelに依存することはお勧めしません。代わりに、すべてのビジネスロジックができるだけControllerで処理され、ViewはControllerとのみやり取りするように要求します。

違いは次の図に示されています（ここでは、提供した元の写真mvc.pngとmvp.pngを参照できます）。

MVVMフレームワーク

MVVMはModel-View-ViewModelの略です。本質的にはMVCの改良版です。MVVMはViewの状態と動作を抽象化し、ビューUIとビジネスロジックを分離することができます。もちろん、ViewModelはすでにこれを実現しています。Modelのデータを抽出し、同時にコンテンツを表示する必要があるため、Viewに関連するビジネスロジックの処理を支援します。MicrosoftのWPFは、Silverlight、オーディオ、ビデオ、3D、アニメーションなど、新しい技術体験をもたらし、ソフトウェアUIレイヤーがより詳細でカスタマイズ可能になりました。同時に、技術レベルでは、WPFはバインディング、依存プロパティ、ルーティングイベント、コマンド、データテンプレート、コントロールテンプレートなどの新機能をもたらします。MVVM（Model-View-ViewModel）フレームワークの起源は、MVP（Model-View-Presenter）パターンとWPFを組み合わせたアプリケーション手法から進化した新しいタイプのアーキテクチャフレームワークです。元のMVPフレームワークに基づいており、ますます複雑化する顧客ニーズの変化に対応するためにWPFの新機能を組み込んでいます。

MVVMパターンのコンポーネント

+-------------------+
|       Model       |
| ドメインモデル（オブジェクト指向）またはデータアクセス層  |
|  （データ中心）、実際の状態コンテンツを表す               |
+-------------------+
          |
          | データを提供する
          ▼
+-------------------+
|     ViewModel     |
|   ビューの抽象化、パブリックプロパティとコマンドの公開、            |
|  ビューとデータバインダー間の通信      |
+-------------------+
          |
          | 双方向バインディング
          ▲
+-------------------+
|       View        |
| ユーザーが画面に表示する構造、レイアウト、外観（UI）         |
+-------------------+

Model: モデルは、実際の状態コンテンツを表すドメインモデル（オブジェクト指向）またはコンテンツを表すデータアクセス層（データ中心）を指します。
View: MVCおよびMVPパターンと同様に、ビューはユーザーが画面に表示する構造、レイアウト、および外観（UI）です。
ViewModel: ビューモデルは、パブリックプロパティとコマンドを公開するビューの抽象化です。MVVMには、MVCパターンのコントローラー、MVPパターンのプレゼンターはありませんが、バインダーがあります。ビューモデルでは、バインダーはビューとデータバインダーの間で通信します。
Binder: 宣言的なデータとコマンドのバインディングは、MVVMパターンで暗黙的に行われます。Microsoftソリューションスタックでは、バインダーはXAMLと呼ばれるマークアップ言語です。バインダーは、開発者がビューモデルとビューを同期させるためのボイラープレートロジックの記述を強制されることから解放します。Microsoftスタックの外部で実装する場合、宣言的データバインディングテクノロジーの出現は、このパターンを実装するための重要な要素です。

MVVMの利点

MVCパターンと同様に、MVVMパターンの主な目的は、ビュー（View）とモデル（Model）を分離することであり、いくつかの大きな利点があります。

疎結合: ビュー（View）は、モデルとは独立して変更および修正できます。1つのViewModelを異なる「View」にバインドできます。Viewが変更されてもModelは変更されず、Modelが変更されてもViewは変更されません。
再利用性: 一部のビューロジックをViewModelに入れて、多くのビューにこのビューロジックを再利用させることができます。
独立した開発: 開発者はビジネスロジックとデータ（ViewModel）の開発に集中し、デザイナーはページデザインに集中できます。Expression Blendを使用すると、インターフェースを簡単に設計してxamlコードを生成できます。
テスト可能性: インターフェースは常にテストが比較的困難でしたが、ViewModelに対してテストを作成できるようになりました。

MVVMとMVPの違い

mvvmパターンは、Presenerの名前をView Modelに変更します。これは、MVPパターンと基本的にまったく同じです。唯一の違いは、双方向バインディング（データバインディング）を使用することです。Viewでの変更は、View Modelに自動的に反映され、その逆も同様です。このようにして、開発者はイベントの受信やViewの更新の作業に対処する必要がなく、フレームワークがすでにそれを行っています。

【Leapcell：最高のサーバーレスWebホスティング】（https://leapcell.io/）

最後に、Webサービスのデプロイに最適なプラットフォームをお勧めします。Leapcell

🚀 お気に入りの言語で構築する

JavaScript、Python、Go、またはRustで簡単に開発できます。

🌍 無制限のプロジェクトを無料でデプロイする

使用量に応じてのみ料金を支払います—リクエストも料金もありません。

⚡ 従量課金制、隠れたコストなし

アイドル料金は不要、シームレスなスケーラビリティのみ。

📖 ドキュメントを見る

🔹 Twitterでフォローしてください：@LeapcellHQ

なぜMVC、MVP、MVVMが最高のアーキテクチャパターンであり続けるのか