さて、これは私が見つけることができる質問ですが、賛成/反対の適切な議論はほとんどありません.
これらのパターンがテスト容易性と関心の分離のために提供する価値を高く評価しています。特に、さまざまな方法でユーザーに提示できる、ある種のデータ ストアがある場合はそうです。
しかし、各モデルが 1 つのビューにのみバインドされているアプリケーションを考えてみましょう。例としては、オーディオ フォーマット コンバーターがあります。これは、(a) 大きな API バックエンドの上にある小さな GUI である可能性があります。UI に必要なのは基本的な検証 (パスとフォーマット) だけで、残りはバックエンドに任せられます。
ここでそのようなパターンの 1 つを使用する利点は、余分なコードを正当化するでしょうか? 個人的には、これは不要なオーバーヘッドだと思いますが、間違っている可能性が非常に高いため、質問です。:-)
編集：
ここで書いたサンプル アプリケーションは、質問の要点から人々の注意をそらしているようです。MVP/MVC が良くない場合に質問しています。以下はゴールデン4からの引用です。
デザイン パターンの使用方法についての議論は、それらを使用しない方法についてのいくつかの言葉がなければ完全ではありません。設計パターンを無差別に適用するべきではありません。多くの場合、追加レベルの間接化を導入することで柔軟性と可変性を実現します。これにより、設計が複雑になり、パフォーマンスが低下する可能性があります。設計パターンは、それが提供する柔軟性が実際に必要な場合にのみ適用する必要があります。
そして、それが質問の要点です。[MVC/MVP] を使用しない方法についてのいくつかの単語が見つからなかったので、質問はまさにそのための試みです。上で述べたように、私はそれらが提供する価値に本当に感謝していますが、それらが恐ろしいアイデアである場合を知りたいです. 確かにずっと良いパターンはありませんか？