新しいプロジェクトで MVC パターンを使用することを検討しています。データ層 (モデル) をプレゼンテーション層 (ビュー) に少し近づけることができるという主な利点がはっきりとわかります。アプリケーションの速度で。しかし、パフォーマンスの観点から離れて、view-logic-data 階層型パターンよりも MVC の利点は他にありますか?
編集: 興味のある方のために、MVC の使用をテストするために作成したサンプル PHP コードをアップロードしました。コードを読みやすくするために、意図的にすべてのセキュリティ チェックを省略しました。あまり批判しないでください。より洗練された高度なものになる可能性があることはわかっていますが、それでも機能します!!! 質問や提案を歓迎します: リンクは次のとおりです: http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip
MVC の利点として引用されている関心の分離は、実際には 3 層/3 層システムの進歩でもあります。ここでも、ビジネス ロジックは独立しており、さまざまなプレゼンテーション層から使用できます。
主な違いは、従来の MVC ではモデルがビューへの参照を持つことができることです。これは、データが更新されると、モデルがこのデータを複数のビューにプッシュバックできることを意味します。代表的な例は、データが複数の方法で視覚化されるデスクトップ アプリケーションです。これは、表とグラフのように単純な場合があります。テーブルの変更 (一方のビューでの変更) は、最初にコントローラーを介してモデルにプッシュされ、次にモデルがそれをグラフ (もう一方のビュー) にプッシュします。その後、グラフはそれ自体を更新します。
デスクトップ開発が衰退しているため、多くのプログラマーは、Java EE の JSF など、いくつかの Web バリアントでのみ MVC に触れています。
そのような場合、モデルがビューへの参照を持つことはほとんどありません。これは、Web が主に要求/応答ベースであり、要求が処理された後、サーバーが追加情報を送信できないためです。つまり、モデルからクライアントにプッシュされた更新は無意味です。リバース ajax/comet ではこれが変わりつつありますが、多くの Web ベースの MVC フレームワークはまだこれを十分に活用していません。
したがって、Web ベースの MVC の場合、M、V、および C の間の典型的な「三角形」は少なくなり、その MVC バリアントは実際には「真の」MVC よりも n 層モデルに近くなります。
また、一部の Web MVC フレームワークには、バッキング Bean (Java/JSF) またはコード ビハインド (ASP.NET) と呼ばれる M、V、および C 間の中間配管部分があることにも注意してください。JSF では、コントローラーはフレームワークによって提供され、ビューは多くの場合、モデルに直接バインドせず、このバッキング Bean を仲介として使用します。バッキング Bean は非常にスリムで、基本的にモデルからデータを一方向にプリフェッチし、モデル固有のメッセージ (例: 例外) をビュー固有のメッセージ (例: 人間が読めるテキスト) に変換するだけです。
それ以外
@bakoyaro と @arjan によってすでに言及されています
「設定より規約」パターンと組み合わせると、MVCは3層よりも優れていると思います。(つまり、「Ruby on Rails」または Microsoft の「MVC for asp.net」)。
私の意見では、この組み合わせにより、コードの保守がより良く簡単になります。
まず、規則を学ぶ必要があるため、mvc-framework の学習が少し難しくなります (コントローラーはコントローラー フォルダーに移動し、xxxxxcontroller という名前にする必要があります)。
しかし、慣例を学んだ後は、独自のコードや外国のコードを維持するのがより簡単になります。
MVC に移行してアプリケーションの速度を上げることは忘れてください。コードの再利用が容易になることが最大の利点であることがわかりました。MVC に移行すると、データの表示や実際のデータのストレージに依存しなくなります。
たとえば、.jsp ページを提供するサーブレットをある日にプレゼンテーション レイヤーとして作成し、翌日には Web サービスを別のプレゼンテーション レイヤーとして既存のモデルとコントローラーに作成することができます。DBMS を切り替えたい、または切り替える必要がある場合も同様です。モデルへのアクセスは他のすべてのものから完全に分離されているため、コントローラーが処理できる方法でデータを返すようにデータ アクセス オブジェクトだけを書き直す必要があります。
懸念事項を 3 つの個別の部分に分けることで、真の単体テストも容易になります。プレゼンテーション レイヤーは、モデルまたはコントローラーなしでテストできます。また、その逆も可能です。
余談ですが、MVC の省略形が不正確だと感じることがよくあります。それを見るたびに、View->Controller->Modelと考えます。プレゼンテーション レイヤーに DAO コードが含まれることはなく、モデルにプレゼンテーション ロジックが含まれることもありません。コントローラーは、仲介者として機能することを余儀なくされています。