MVCでどのくらいのGUIロジックが多すぎますか？

Question

私は小さなJavaデスクトップアプリケーションを書いています。私はMVCパターンを使用しています。私はモデルにロジックを保存する方法については読んだことがありますが、ロジックを適用しなければならない場所がいくつかありますが、GUIの機能に完全に関連しています。また、レイヤーは「プラグイン」ビューを許可するように設計する必要があります。つまり、アプリをコマンドラインアプリに変えたい場合は、同じモデルを最小限の問題で使用できるはずです。

私のアプリでは、画像が分割パネルの1つのペインに表示されます。また、ユーザーがペインのサイズを変更したときにイメージのサイズが動的に変更されるかどうかを決定するチェックボックスもあります。

1. ユーザーがチェックボックスをクリックする

   は、値が モデルに格納されます：私は2つの解決策を持っているような気がします。ペインのサイズが変更されるたびに、その値が確認されて画像が拡大縮小されるかどうかが確認されます（ ）。

2. チェックボックスのみどのようにGUI機能に関連するので、私は モデルに値を格納する気にしないだろう、と私はウィンドウのサイズ変更に直接 チェックボックスを確認することになります。

これは少し下の例ですが、私の問題を示しています。私は論理の分離をあまりにも極端に取っていますか？

Answer 1

「ロジック」は、MVCのための3つのカテゴリーに分けることができます。

• 検証ロジック - これがモデルにする必要があります。
• ビジネス/リポジトリロジック - これはコントローラ内にある必要があります。
• 表示と動作ロジック - これはビューにある必要があります。

この例では、あなたの行動ロジック（つまり、ビュー）にいるようです。

Answer 2

すべてのロジックをビューから切り離す必要はありませんが、ビジネスロジックは間違いありません。

私は別のクラスにもUI関連のロジックを抽出しますが、Separation of Concernsの場合はそうです。

懸念の分離のための実効的な経験則は、「要件が変更された場合（UI、検証などに関して）、私のアプリケーションのどの部分/クラスを変更しなければならないでしょうか？

Answer 3

Presentation Modelをご覧ください。

プレゼンテーションモデル：

は独立して、私はこの問題全体に何度も来ているインタフェース

で使用 GUIコントロールのプレゼンテーションの状態と動作を表します。あなたが次のことをするように求められていると想像してください。

制御Bは、月曜日の場合に表示する必要があります。

これは、ビジネスロジックであり、ビューに含まれてはいけません。ビューは、このタイプのロジックに関係していてはなりません。ビューが知る必要があるのは、特定のコントロールを表示する必要があるかどうかである。したがって、これを実現するには、ビューに必要なすべての適切なプロパティと、というプロパティがisBVisibleというクラスを持つことができます。このプロパティーisBVisibleは、サービスレイヤーから塗りつぶされている可能性があり、ビューに必要なオブジェクトを表示してデータを表示します。

Answer 4

最初のものは真のMVCです。第二はありません。 MVCは、kostjaが述べたように、分離の懸念のために特に重要です。大規模なプロジェクトでは、これはどこで何が起こっているのかを把握するために重要です。小規模なプロジェクト（一回限りであるか、プロダクション環境で使用されないか、ハウスツールなどにある）では、それほど問題はありません。