iOS MVCアプリケーションに関する懸念の分離

Question

私は特に、優れたMVCパターン設計に関してAppleの基準に従う方法に興味があります。私の質問を例で説明しましょう。

UITableViewのようなかなり複雑なUI要素が画面上にあるとします。基本的にこれらの要素は、データソースとデリゲートが対話を処理する必要があります。

これには2つのアプローチがあります。

UITableViewControllerのすべての要素を処理し、要求するUITableViewに基づいて動的に処理するサブクラスを持つことができます。

第2のアプローチは、個々のビューを管理する「軽量」コントローラを持つことです。 iOS 4.xでは複数のUIViewControllerを持つことはできませんので、これらのコントローラは状態と対話を管理するためのものです。

私は最初のアプローチが肥大していないし、物事を結合しているようだから嫌いです。異なるタイプの複数の複雑なオブジェクトがある場合はどうなりますか？

第2のアプローチが優れているようです。オブジェクトはよりよくカプセル化されます - 懸念の分離。唯一の欠点は、コミュニケーションの複雑さの増加です。軽量コントローラーは、実際のビューコントローラーに委譲するか、実際の操作を実行するために何かを処理する必要があります。

これらのアプローチのいずれかの経験はありますか？複雑なインターフェイスを分解するためのより良いソリューションはありますか？

おかげ

Answer 1

あなたはいつも何か他のものへのUITableViewのデリゲートとデータソースを再割り当てすることができます。それはUITableViewControllerである必要はありません。デリゲートとデータソースのための1つのプロトコルメソッドを満たす限り。

したがって、nib/xib（Interface Builderで作成されたビュー）によって強化されたUIViewController（コントローラ）があるかもしれません。そのインターフェイスでは、テーブルビューを追加して、デリゲートとデータソースをファイル所有者に設定しました（コントローラに戻る）。

次に、UIViewControllerは、Core Data（モデル）と通信して、UITableViewデリゲートメッセージに応答して関連オブジェクトを取得します。

または、UIViewControllerは、デリゲート/データソースをカプセル化しやすくするプロトコルを満たす軽量プロバイダに再割り当てできます。

これはAppleが提案しているMVCのスタイルです。