Apple の MVC パターンに関する入力処理について少し混乱しています. Apple によると、オブジェクトはモデル オブジェクト (データを処理する)、ビュー オブジェクト (データを表示する)、およびコントローラー (2 つをバインドし、イベントと入力を処理する) に分割する必要があります。ただし、Apple のネイティブ UIKit ビュー (UIScrollView、UIControl オブジェクトなど) の多くは、すべての入力処理を自分で行い、デリゲートとデータ ソースを介してコントローラーに通知する可能性があります。これは本当に私を混乱させます。私の考えでは、MVC トライアドの頑丈さは、モデルとビューの両方がかなり馬鹿げている (したがって、簡単に交換できる) ことにかかっています。すべての OS レベルの複雑なイベントがコントローラーに集中化されている場合、問題は非常に適切に分離されます。一方、ビューに入力処理を追加すると、それ自体が一種のコントローラーになるようです。
ここで何か不足していますか？これについてどう考えるのが正しいですか？
ユーザー入力は、MVC パターンのビューの一部です。それらはユーザーと直接やり取りし、要求に応じて、または委任を通じて、データをControllerに提供します。 Controller は、その入力を使用してModelに変更を加える場合があります。
「ばか」と「簡単に交換可能」は、必ずしも同じものではありません。
ボタンには、すべてのコントローラーで書き直したくはない多くの機能が含まれています: 強調表示を示すための画像の色付け、タッチアップの前にタップが一定距離離れた場合のキャンセルの許可など。物理。
言い換えれば、「どのようなものを表示するか」は、ビューオブジェクトの誤った特徴付けです。基本クラスの UIView はイベント データを提供するだけですが、サブクラスは「ボタンがタップされた」や「スクロール ビューが減速して停止した」などの高レベルのデータを提供します。
考えるべきことの1つは、あなたの視点です。
私たちのほとんどがコーディングするとき、モデルはデータ オブジェクト (おそらくファイルやデータベースなどに基づく) であり、ビューはUIView(おそらく Interface Builder でセットアップ/構成された) であり、コントローラーはUIViewControllerです。
アプリのコーディングをしていない場合はどうでしょうか。あなたの世界が だったらUITableView？基本的な MVC 分離を引き続き使用できます。モデルはUITableViewDataSourceプロトコルで表され、ビューはまだUIViewセットアップと構成で表され、コントローラーはUITableViewDelegateプロトコルです。そこにすべてのピースがあり、分離されていても、分離は を使用する場合とはまったく異なりUIViewControllerます。データ変更の分離の実用的な例を見ることができます。データ ソース プロトコルでデータを取得しても、何も起こりません。reloadDataデータが変更されたことを認識するために、テーブルのコントローラー ビットでメソッドを呼び出す必要があります。
アイテムが小さいほど、MVC パターンが見えにくくなります。「ボタン」を 3 つの異なるオブジェクトに分割すると、使用が非常に難しくなりますが、1 つのオブジェクト内で MVC パターン化を使用して、カプセル化されたものを作成できます。AUIButtonには、パブリックプロパティとプライベートプロパティの両方の形式のモデル、ビュー（UIViewまだ）、およびイベントを受け入れてビューやモデルを適切に変更する一連のコードであるコントローラーがあります。