0

今後のプロジェクトでは、MVC のオプションとして MVP を検討しています。私は MVC に非常に精通しており、MVC が好きです。MVP を使用して何か得られるかどうかを確認しようとしているだけです。

MVP について私が収集したのは、ViewState を使用する ASP.Net ビュー エンジン/MVC# (これは特に好きではありません) を使用しているということです。レンダリングされた Web ページに大量の余分なコンテンツを追加し、ルーティング機能は組み込まれていません。 (Global.asax に個別に書き込むことができます)。

一方、MVC/Razor は非常にクリーンな HTML をレンダリングします。

このような特定の記事では、複数のビューに MVP を使用する傾向があるように見えますが、jQuery Mobile を使用した MVC3 を考慮すると、この MVC で実現できる素晴らしいことがいくつかあります。

これらは現在 MVP で利用できるものと比べてどうですか? MVC よりも MVP を使用することの長所/短所、または潜在的な落とし穴は何ですか?

また、既存の MVP アプリケーションを使用して開発時間を短縮することも検討しています。

次のことにうんざりすることはわかっていますが、オプションを探しています。 このアプリは必要なすべての機能を提供しますが、このソリューションを実装する場合、追加の MVC アプリケーションを結び付けるのはどれほど難しいでしょうか (見た目が悪いことはわかっています)。これが (両方を組み合わせて) 考慮しなければならないものである場合、アプリケーションを MVC (ルーティング) でラップし、MVP アプリを内部に含めるのが最善でしょうか?

この理由は、機能の更新プロセスがずらされているためです。要件は、新しい機能 (MVC フレームワークを使用して構築されていますが、システムの残りの部分は MVC フレームワークを使用して構築されていません) を実装することです。将来の計画は、現在のフレームワークを MVC または MVP に完全に変更することです。

ありがとう。

4

1 に答える 1

1

ここでフレームワークとパターンを混同しているようです。

MVC と MVP はどちらも設計パターンであり、ASP.net MVC と MVC# は MVC/MVP 設計パターンを実装するフレームワークです。

MVC と MVP のパターンの違いについては、ウェブ上で大規模な混乱と多くの相反する情報があり、事実、パターンを「引退」してから 2 つの新しいパターンを支持して MVP を普及させた人物である Martin Fowler がいます。こちらをご覧ください

両方のパターンは確かに懸念の分離を支援するためにありますが、それらの間に大きな違いはないことを除けば、私が見つけた唯一のことは、MVC には画面上のウィジェットごとにコントローラーがあり、MVP は 1 つです。ただし、複雑な画面がある場合は、このルールにも違反します。私はまだ確信が持てず、自分自身で用語を同じ意味で使用しています.

私が何度も目にすることの 1 つは、MVP ではビューがプレゼンターの作成を担当しているということですが、これは元の設計の一部ではありません。これは、asp.net Web フォームなどの古い Web フレームワークがページ中心であったという事実から発生したようです。これを変更する方法がなかったため、プレゼンターを作成したのはページ (ビュー) でした。基本的に、フレームワークはパターンの邪魔になるため、ハックしてそれを組み込むようにしました。残念ながら、これは MVP を説明するための事実上の方法になっているようです。

基本的に、上記のテキストの壁は、MVC を適切に使用するために設計されたフレームワークを使用する場合は、ASP.net MVC が適切な選択であり、MS スタックの一部であり、十分にサポートされていることを伝えようとしています (MVC# はサポートされていません)。 2008 年以降に更新されています) そして、もしあなたがすでにそれに満足しているなら、何か他のことを学ぼうとして生産性を失うことは本当に価値がありません.

于 2012-02-20T15:12:23.460 に答える