web-dev-qa-db-ja.com

旧式の3層パターンに対するMVCパターンの主な利点は何ですか

私は新しいプロジェクトでMVCパターンを使用することを考えており、データレイヤー（モデル）をプレゼンテーションレイヤー（ビュー）に少し近づけることができるという主な利点を明確に理解できます。アプリケーションの速度。しかし、パフォーマンスの観点とは別に、view-logic-dataレイヤードタイプパターンを超えるMVCの利点はありますか？

EDIT：興味がある人のために、サンプルをアップロードしましたPHP MVCの使用をテストするために作成したコード。コードを読みやすくするために、すべてのセキュリティチェックを意図的に省略しました。もっと洗練されて高度になる可能性があることを知っているので、あまり批判しないでください。質問と提案：リンクは次のとおりです。 http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.Zip

model-view-controllerdesign-patternsn-tier-architecture3-tiern-layer
32
techexpert

MVCの利点として引用されている懸念の分離は、実際には3層/ 3層システムの進歩でもあります。また、ビジネスロジックは独立しており、さまざまなプレゼンテーション層から使用できます。

主な違いは、クラシックMVCでは、モデルがビューに戻る参照を持つことができることです。つまり、データが更新されると、モデルはこのデータを複数のビューにプッシュバックできます。主な例は、データが複数の方法で視覚化されるデスクトップアプリケーションです。これは、表とグラフのように単純にすることができます。テーブルの変更（一方のビューの変更）は、最初にコントローラーを介してモデルにプッシュされ、次にモデル（もう一方のビュー）にプッシュされます。その後、グラフは自動的に更新されます。

デスクトップ開発は減少傾向にあるため、多くのプログラマーは、Webバリアント（例： Java EE。

そのような場合、モデルにはビューへの参照がほとんどありません。これは、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は非常にスリムで、基本的にモデルからデータを一方向にプリフェッチし、モデル固有のメッセージ（例外など）をビュー固有のメッセージ（人間が読めるテキストなど）に変換します。

42
Arjan Tijms

横に

  • コードの再利用、
  • 懸念の分離、
  • 層間の結合が少ない、

@bakoyaroと@arjanによって既に言及されています

"convention over configuration"パターンと組み合わせた場合、MVCは3層よりも優れていると思います。 （つまり、「Ruby on Rails」またはMicrosoftの「asp.net用MVC」）。

私の意見では、この組み合わせはコード保守の改善と改善につながります。

そもそもmvc-frameworkの学習は、慣習を学ばなければならないのでもう少し難しくなります（laコントローラーはコントローラーフォルダーに入り、xxxxxcontrollerという名前にする必要があります）

ただし、規則を学習した後は、独自のコードおよび外国のコードを維持する方が簡単です。

6
k3b

MVCに移行して、アプリケーションの速度を上げることを忘れてください。私は、コードの再利用が簡単であることの最大の利点を発見しました。 MVCに移行すると、データの表示や実際のデータの保存に依存しなくなります。

たとえば、ある日、プレゼンテーション層として.jspページを提供するサーブレットを作成し、翌日、既存のモデルとコントローラーに別のプレゼンテーション層としてWebサービスを作成できます。 DBMSを切り替えたい場合、または切り替える必要がある場合は賢明です。モデルへのアクセスは他のすべてから完全に分離されているため、コントローラーが処理できる方法でデータを返すには、データアクセスオブジェクトだけを書き直す必要があります。

懸念事項を3つの個別の部分に分けることで、真の単体テストも容易になります。プレゼンテーションレイヤーは、モデルまたはコントローラーなしでテストでき、その逆も可能です。

副次的に、私はMVCの略語が不正確であるとしばしば感じました。私はそれを見るたびにView-> Controller-> Modelと考えます。プレゼンテーションレイヤーにはDAOコードが含まれることはなく、モデルにはプレゼンテーションロジックが含まれることはありません。コントローラーは、仲介役としての役割を強制されます。

2
bakoyaro

3層がプレゼンテーションをビジネスおよびデータアクセスから分離する場合、MVCはモデル（データ）をビュー（画面）およびコントローラー（入力）からさらに分離するプレゼンテーションレイヤーパターンです。

3層/ 3層よりもMVCを選択する必要はありません。両方を使用します。

0
SuperGirl