複雑なiPadアプリのMVCデザインパターン：1つの太ったコントローラが受け入れられますか？

Question

私は複雑なiPadアプリケーションを構築しています。それをスクラップブックと考えてください。 この質問の目的のために、その上に2つの画像があるページを考えてみましょう。
メインビューには、私のドキュメントデータが単一のUIImageとして表示されます。これは私がそれらに対していくつかのグローバルな操作を行う必要があるためです。これは私のDisplayViewです。
編集時私はEditorViewを、2つの画像をサブビューとしてインスタンス化する必要があります。この方法で、私は単一の画像とやりとりすることができます（回転、スケール、移動）。編集がトリガーされると、私はDisplayViewを隠し、EditorViewを表示します。

iPhoneアプリケーションでは、各メインビュー（つまり、画面に表示されるビュー）をView Controllerに関連付けます。
ここに問題があるのは、ただ1つのView Controllerだけです。私はEditorViewをモーダルビューコントローラで渡すことを検討しましたが、オプションではありません（マスクとすべてのパレットをカバーする複雑なレイアウトがあり、EditorViewの再構築で重複したコードが作成されます）。

現在、EditorViewにはロジックが組み込まれています（モデルからデータをロードし、細かい編集のためにいくつかのサブビューを呼び出し、モデルにデータを戻します）。 EditorViewサブビューにもロジックが組み込まれています（画像を操作してメインEditorViewに戻します）。私はこの論理がコントローラにもっと属していると感じています。一方、私の唯一のビューコントローラをとてもすごくいいアイデアにしているのかどうかはわかりません。

このようなクラス構造の中で、最高のココアアイシー実装は何ですか？
説明を求めても構いません。
乾杯。

Answer 1

巨大脂肪コントローラは問題ありません。

必要に応じて、「純粋に論理的な部分」を一部破棄し、他の「ヘルパークラス」に移動します。また、カテゴリのようなトリックをできる限り広範囲に使用してください。

HFC（巨大脂肪コントローラ）があれば間違いないと思います。

次に、エンジニアリング用の自転車に乗り、地獄をスリムにしてください！

1つのものが大きすぎるため、適切な構造、良い構造、必要な構造を避けてはいけません。

アウトソーシングのコンセプトや、カテゴリのナット、その他など、この本の中のすべてのトリックで、大きなものをスリムにしてください。

私の信念！

Answer 2

ビューの周りのViewControllerをラップするいくつかの理由：

• のViewController（ポップオーバービュー、モーダルビュー、ナビゲーションバー、タブバー、...）

  を必要とするアップルのAPIでそれを使用します

• ビューはしばらく表示されない可能性があるため、メモリーが少ない状況でビューをクリーンアップすることができます。ビューコントローラは、アンロード・リロード・サイクルに耐える必要があるデータを保護します。

• あなただけのMVCパターン

のように私は2番目の箇条書きは、あなたの編集可能なコンテンツビューとあなたの非編集可能なコンテンツビューのための別の1のためのViewControllerを正当化すると思うので。