どちらを選択するか（MVCまたはMVP）を尋ねているのではなく、2つのうちの1つをWebアプリケーションに使用する必要があるかどうかを尋ねていることに注意してください。
古いアプリケーションを現在の設計からMVCまたはMVPパターンに変換するのは大変な作業かもしれないことを私は理解しています。しかし、新しいアプリはどうですか？これらは最も人気のあるアーキテクチャパターンのようですが、そのうちの1つを選択する必要がありますか？そうでない場合、他にどのようなパターンがありますか？
MVCやMVPに精通していない場合は、「MVPとMVCとは何ですか、違いは何ですか？」を確認することをお勧めします。。それぞれを分解するさまざまなウェブサイトへのリンクを含む、多くの良い答えがあります。
MVP / MVCは、HTTP動詞とURLの組み合わせが、実行するアクションを決定するための非常に優れた方法であるため、Webアプリケーションで適切に機能します。チームが別のフレームワークの経験が豊富な場合など、使用しない理由はありますが、通常はMVP/MVCフレームワークをお勧めします。アプリケーションは、より高品質でより迅速に終了します。
I have posted the following answer for another question, though it may be more appropriate here.
MVC is good for plain server side scripting. In MVC developers always try to keep the controller very lean. Mainly controller is for just selecting the appropriate model and reflect on the view. But in today's web applications the View part has radically changed and became complex enough to produce a big, fat and messy controller. So now we need a new place to put the user interface's complex control logic. Here the P of MVP comes in that is the presenter. So presenters are responsible for controlling the logic for a particular user interface component. Don't worry the controller is still here, named as Application Controller. Which ultimately responsible for switching between comparatively larger application components. So MVP can also be said MVPC(!!). BTW this was my way of understanding MVP and obviously not any ground rule.
So I am already tend to MVP for complex web apps.
どちらも素晴らしいオプションです。
MVC の方が広く採用されており、フロントエンド (HTML / CSS) 開発者にとって理解しやすく、使いやすいため、私は MVC を選びます。
また、MVC パターンを採用しているフレームワークの数を考慮すると、チャンチは MVC で同僚と話しているので、よく知られている言語を話します。
あなたの質問は「これらのデザインパターンの1つを使用すべきか」でした。
それは本当にあなたのプロジェクトの範囲に依存していると言わざるを得ません。予算の大きい大規模な組織で他のシステムと相互依存している非常に大規模なプロジェクトでは、それらを検討する価値があると思います。
これらのパターンは、不必要な複雑さとコストを追加する可能性のある小規模なプロジェクトで頻繁に使用されていると思います。
緩い結合の主なポイントは、後でDBまたはUIを変更したり、ビジネスロジックを再利用したりできるようにすることです。多くの場合、これは決して起こりません。これらのパターンのいずれかは、コードの実装と複雑化にかなり時間がかかることを理解する必要があります。ですから、これを真剣に考え、選択肢を検討することを強くお勧めします。多くの場合、作業を完了して複雑さを軽減する非常に単純なアーキテクチャを使用することで、より優れたソリューションをより迅速に提供できます。
使用しているフレームワークによって異なります。サポートされているものだけを使用してください。私が見たほとんどの Web フレームワークは、フロント コントローラー パターンを使用し、MVC または MVP と呼んでいます。
私はあなたがすべきだと思います。Web フォームをプッシュし、Web アプリケーションの構築をより簡単にするためにあらゆることを行ったため、特に MS の世界では実装が困難です。
それらを使用すると、簡単にプログラミングでき、多くの作業を行ったように感じます。ただし、サイトが大きくなると、速度が遅くなり、維持するのが難しくなります。
MVC と MVP を使用すると、モデル (使用しているドメインを表す基本クラス)、コントローラー、およびビューを分離できます。これの最も良い点は、モバイル アプリケーションや Windows アプリなどの他のアプリケーションでモデルを再利用できることです。それらには単なるデータベース以外の共通点があるため、記述するコードが少なくて済みます。コントローラーとビューを作成するだけです。
私はこれに慣れていませんが、ある場所で何かを変更しなければならなかったときに別の場所で何かがクラッシュしたため、利点が見られます(したがって、疎結合を考慮して単体テストを作成する必要もあります)。Web フォームではテストを書くことはできません。
ただし、Web 上にビジネス ロジックがなく、迅速に実行する必要がある個人または会社を表すアプリケーションを作成する場合は、Web フォームが適しています。また、プロトタイプを作成して、アプリケーションが完成したときにどのようなことができるかを示すこともできます。
どちらのパターンも好きです。私のベスト プラクティスは、パターンを選択することです。
私は両方のパターンで多くのアプリケーションを開発してきました。私の個人的な感覚では、あなたが RAD 開発者であり、CSS と JavaScript が苦手な場合 (ほとんどの場合、Web アプリケーションを作成したい winforms 開発者です。不快ではありません ;-) ) すべきです。 MVP パターンを使用すると、Web アプリケーション プロジェクトで非常に簡単に使用できます。
しかし、CSS と JavaScript の割り当てを知っている場合は、ASP.NET MVC パターンを検討する必要があります。
疎結合という理由だけで、MVCパターンを好みます。モデル、ビュー、およびコントローラーの間には明確な分離があり、分離により、テスト駆動開発または単体テストにより適しています。