こんにちは、同僚の皆さん。 この記事では、MVC、MVP、およびMVVMパターンの違いに関する分析的理解についてお話したいと思います。 大規模なソフトウェアおよび関連するアーキテクチャ機能の開発における最新のアプローチを理解したいという願望から、私はこの記事を書くことに触発されました。 私のキャリアの梯子の現在の段階では、私は直接の開発者ではないので、記事には誤り、不正確さ、誤解が含まれている可能性があります。 プログラマーやアーキテクトが何をするのか、アナリストはどのように見ているのでしょうか？ それから猫にようこそ。
参照資料
まず始めたいのは、この記事を書く過程で私を導いた外部資料へのリンクです。
はじめに
太陽がより明るく輝き、草がより緑になった当時、学生のチームは、この記事の著者として、製品インターフェースに数百行のコードを直接書くことでソフトウェアを開発しました。 データを操作するためにサービスとマネージャーが使用され、ドキュメントビューパターンを使用してソリューションが取得される場合がありました。 このようなコードをサポートするには莫大な費用が必要でした。なぜなら、新しい開発者は、どのコードが製品の何に責任があるのかを知るためにトレーニングする必要があり、ユニットテストについては話がなかったからです 開発チームは、同じ部屋に座っている4人です。
時間が経ち、仕事が変わった。 開発されたアプリケーションはより大きく複雑になり、単一のまとまりのある開発チームから、多くの異なる開発チーム、アーキテクト、ユーザビリティー、デザイナー、PMがいました。 現在、GUI、ビジネスロジック、コンポーネントなど、誰もがそれぞれの分野に責任を負っています。 分析、テスト、アーキテクチャの部門がありました。 ソフトウェア開発のコストは、数百または数千倍に増加しています。 このような開発アプローチには、製品のさまざまな機能領域を相互に同期させる安定したアーキテクチャが必要です。
パターン
複雑なソフトウェアの開発にかかる人件費を削減するという目標を考えると、既製の統合ソリューションを使用する必要があると考えています。 結局、ステレオタイプ化されたアクションにより、開発者間のコミュニケーションが容易になり、よく知られているデザインを参照できるようになり、エラーの数が減ります。
ウィキペディアによると、パターンとは、頻繁に発生するコンテキスト内の設計問題の解決策である、反復可能なアーキテクチャ設計です。
最初の主要なモデルであるModel-View-Controllerから始めましょう。 MVCは、多くのテクノロジーに適用され、新しいテクノロジーを生み出し、開発者にとって日々の生活を楽にする基本的なパターンです。
MVCパターンは、SmallTalkで初めて登場しました。 開発者は、グラフィカルインターフェイスをビジネスロジックから分離し、ビジネスロジックをデータから分離できるアーキテクチャソリューションを考案する必要がありました。 したがって、クラシックバージョンでは、MVCは3つの部分で構成され、名前が付けられています。 それらを考慮してください：
モデル
モデルの下では、通常、アプリケーションの機能的なビジネスロジックを含む部分が理解されます。 モデルは、製品の他の部分から完全に独立している必要があります。 モデルレイヤーは、設計要素とその表示方法について何も知らないようにする必要があります。 モデル自体に触れることなく、データの表示、表示方法を変更できる結果が得られます。
このモデルには次の機能があります。
- モデルは、アプリケーションのビジネスロジックです。
- モデルにはそれ自体に関する知識があり、コントローラーと表現については知りません。
- 一部のプロジェクトでは、モデルは単なるデータレイヤー（DAO、データベース、XMLファイル）です。
- 他のプロジェクトの場合、モデルはデータベースマネージャー、オブジェクトのセット、または単なるアプリケーションロジックです。
表示する
プレゼンテーションの義務には、モデルから受け取ったデータの表示が含まれます。 ただし、パフォーマンスがモデルに直接影響を与えることはできません。 ビューにはデータへの読み取り専用アクセス権があると言えます。
ビューには次の機能があります。
- ビューは、何らかの方法でモデルから取得されたデータの表示を実装します。
- 場合によっては、ビューにビジネスロジックを実装するコードが含まれている場合があります。
プレゼンテーションの例：HTMLページ、WPFフォーム、Windowsフォーム。
MVCとMVVMとMVPの違い
最も一般的なタイプのMVCパターンは次のとおりです。
- モデルビューコントローラー
- モデルビュープレゼンター
- モデルビュービューモデル
それぞれを検討して比較します。
モデルビュープレゼンター
このアプローチにより、ビューの抽象化を作成できます。 これを行うには、特定のプロパティとメソッドのセットでプレゼンテーションインターフェイスを強調表示する必要があります。 次に、プレゼンターは、インターフェイスの実装へのリンクを受け取り、プレゼンテーションイベントにサブスクライブし、要求に応じてモデルを変更します。
発表者のサイン：- プレゼンテーションとの双方向通信。
- プレゼンテーションは、プレゼンターインスタンスの対応する関数またはイベントを呼び出すことにより、プレゼンターと直接対話します。
- プレゼンターは、ビューによって実装される特別なインターフェイスを使用して、Viewと対話します。
- 1つのプレゼンターインスタンスが1つのディスプレイに関連付けられています。
実装：各ビューは適切なインターフェースを実装する必要があります。 プレゼンテーションインターフェイスは、ユーザーとの対話に必要な一連の関数とイベント（たとえば、IView .ShowErrorMessage（string msg））を定義します。 プレゼンターには、対応するインターフェイスの実装へのリンクが必要です。これは通常、コンストラクターで渡されます。
プレゼンテーションロジックには、プレゼンターインスタンスへのリンクが必要です。 プレゼンテーションイベントはすべて、処理のためにプレゼンターに送信され、プレゼンテーションロジック（他のビューの作成を含む）によって処理されることはほとんどありません。
使用例：
Windowsフォーム。モデルビュービューモデル
このアプローチにより、プレゼンテーション要素をビューモデルのプロパティとイベントに関連付けることができます。 このパターンの各層は、別の層の存在について知らないと主張することができます。
Viewモデルの兆候：- プレゼンテーションとの双方向通信。
- ビューモデルは、ビューの抽象化です。 通常、ビューのプロパティはビューモデル/モデルのプロパティと同じであることを意味します
- ビューモデルには、プレゼンテーションインターフェイス（IView）への参照がありません。 ビューモデルの状態を変更すると、ビューが自動的に変更され、その逆も同様です。これは、バインディングメカニズムが使用されるためです。
- Viewモデルの1つのインスタンスが1つのディスプレイに関連付けられています。
実装：このパターンを使用する場合、ビューは対応するインターフェース（IView）を実装しません。
ビューには、データソース（DataContex）（この場合はビューモデル）へのリンクが必要です。 ビューのバインド要素は、ビューモデルの対応するプロパティとイベントに関連付けられます。
次に、Viewモデルは、プレゼンテーション要素を自動的に更新するために使用される特別なインターフェイスを実装します。 WPFのこのようなインターフェイスの例は、INotifyPropertyChangedです。
ケーススタディ：
WPFモデルビューコントローラー
このパターンの主な考え方は、コントローラーとビューの両方がモデルに依存するが、モデルはこれらの2つのコンポーネントに依存しないということです。
コントローラーサイン- コントローラーは、現時点でどのビューを表示するかを決定します。
- ビューイベントはコントローラーにのみ影響し、コントローラーはモデルに影響を与え、別のビューを定義できます。
- 1つのコントローラーのみで複数のビューが可能です。
実装：コントローラは外部からイベントをキャプチャし、その中に規定されているロジックに従って、適切なメソッドを呼び出してモデルを変更することにより、このイベントに応答します。 変更後、モデルは変更されたイベントを使用し、それをサブスクライブしているビューのすべてのイベントはそれを受信し、更新されたデータをモデルに渡して表示します。
ケーススタディ：
MVC ASP.NETまとめ
MVVMおよびMVPパターンの実装は、一見、かなり単純に似ています。 ただし、MVVMの場合、ビューとビューモデルのバインドは自動的に行われます。MVPの場合は、プログラムする必要があります
MVCはプレゼンテーションをより細かく制御できるようです。
一般的なパターン選択ルール
MVVM
- 特別なプレゼンテーションインターフェイスを入力する必要なくデータバインディングが可能な状況で使用されます（つまり、IViewを実装する必要はありません）。
- 一般的な例はWPFテクノロジーです。
MVP
- データバインディングが不可能な状況で使用されます（バインディングは使用できません）。
- 一般的な例は、Windowsフォームの使用です。
MVC
- プレゼンテーションとアプリケーションの他の部分との間の通信が不可能な状況で使用されます（MVVMまたはMVPを使用できません）。
- よく使用されるケースはASP.NET MVCです。
おわりに
結論として、この記事の著者は、1つのパターンのみを厳守することが常に最良の選択とは限らないことに注意したいと思います。 たとえば、MVVMを使用して、Bindingsコントロールプロパティを介してWindowsフォームを使用するアプリケーションを開発したいとします。 目標は、プレゼンテーションをビジネスロジックとそれらを接続するロジックから分離することです。 アプリケーションはテストと保守が簡単で、アナリストが理解できるものでなければなりません（結局のところ、「ハードドライブの動作とは何か」という質問に対する唯一の答えはジュールにあります（モデルの抽象的な例->ビュー）。
お時間をいただきありがとうございます、読書をお楽しみください！