Cocoa-Touch で作業していますが、これは一般的な質問です。
ビューがビュー コントローラへの参照を保持し、データを処理しても問題ありませんか? 私は最近、アプリ全体でこれを行うコードベースに出くわしました-たとえば、テーブルビューコントローラーがあり、そのセルにはビューコントローラーへの弱い参照があります(したがって、保持サイクルはありません)。セルは、新しいView Controllerを介して提示します
[self.parentVC presentViewController.....];
同様の方法でそれを却下します。また、データ/ネットワーク操作の変更も処理します。
これを見るまでは、セルごとにプロトコルを作成し、それらを介して親ビュー コントローラーと通信することに慣れていました。View Controller を直接参照するアプローチを使用すると、すべてのプロトコルが削除されます。
私にはこれは本当に悪いように思えますが、それが一般的かどうかはわかりません。
今後の回答は、モデル ビュー コントローラーを処理する Apple の方法に関するものです。これは、他の SDK (例: Qt ) とはまったく異なります。
これは間違いなく悪い習慣です。そして、これは 1 つの質問に要約できます。これが良い考えだと思うなら、なぜ Apple はUIViewクラスにその参照をまだ追加していないのですか?
Apple が model View Controllerをどのように使用しているかを見ると、モデルは非常に明確です。
ビューはコントローラーと通信してステータスの変更を通知し、コントローラーは必要に応じてモデルを更新し、それに応じてビューを更新します。ビューがスタックコントローラーを更新するAppleのドキュメントやサンプルは決して見つかりません。
サブクラスがそれを保持しているコントローラーへの参照を保持し始めた場合UIView(弱い参照であっても)、そのコントローラーに対するビューの抽象化を削除していることになり (参照は逆方向になります)、したがって、同じコードに取り組んでいる人。
今回、ビューがアタッチされている「モデル」に別の開発者が参照を追加するのを妨げるものは何ですか?
これがあなたのコードをスパゲッティコードに変えると言っているのではありません（おそらくそれからまともなアプリを作ることができます）、これは本当に（本当に！）悪い習慣だと言っています。
これが十分に明確であることを願っています。
うーん… 珍しくないし、スタイルもあまり良くない。私は自分でそれをしましたが、ほとんど迷子になりました。必要なときはいつでも、デリゲート パターンを採用するようにしています。つまり、はい、たまたまView Controllerであるデリゲートへの参照を保持しています。デリゲート オブジェクトは、呼び出しようとしているビュー コントローラー (デリゲート) のすべてのメソッドを要約するプロトコルを満たしています。
その場合、あなたの例では、セルはメソッドを呼び出すことによって何かが起こったことをView Controllerに通知し、View Controllerは次に呼び出されるView Controllerを呼び出します。
そうすることで、同じことを達成できますが、MVC パターンに固執しているため、1 年ほどでも、どのような機能をどこで探すべきかを常に知っています。
私はおそらく両方だと思います：本当に悪いことと一般的なことです。
ビューは汎用的である必要があり、コントローラーに関する詳細を知る必要はありません。通信は、委任 (プロトコル)、データ ソース (プロトコル)、またはターゲット アクションに制限する必要があります。