原則として、ドラッグ処理の主な責任は、NSView または NSViewController のどこに属しますか。
ドラッグ操作フックはすべて NSView に含まれているため、NSView が自然な場所のようです。さらに、ビューは何らかの役割を果たす必要があります。なぜなら、ビューは物事がどこにあるかを知っているため、当然、ドラッグが巻き上げられる場所の専門家だからです。
しかし、ドラッグは通常、ドキュメント間またはプロセス間通信に関するものであり、最も具体的には、ファイルを Finder からドキュメントにドラッグすることに関するものです。ドラッグは、モデルに変更または追加をもたらすようにバインドされています。そして、それがコントローラーの仕事です。
最後に、ビューまたはコントローラーのどちらにいるかに関係なく、通常、プロセス内のドラッグを処理してからデータを受け取るための一連のメソッドを追加します。メソッドをビューまたはコントローラーに追加するだけですか、それともポリシー オブジェクトに転送しますか?
NSView はドラッグ処理の「最前線」です。ご指摘のとおり、「ビューは物事がどこにあるかを知っているため、当然、ドラッグが巻き上げられる場所の専門家です」。すべての人を代弁することはできませんが、私が見たパターンは、ボタンのような単純なビューと同じように、ビューが「ユーザー インテント」を受け取ると、それをコントローラー オブジェクトに伝えるというものです。
シンプルな NSControls は、IB に接続できるターゲット/アクション パラダイムを使用してこれを行います。ここでの簡単なアプローチの 1 つは、ビューのターゲット/アクションを指定することです。ドラッグ操作がアクションをトリガーする時点まで進行すると、ビューはそれを実行できます。senderビューがコントローラーに伝達する必要がある状態は、アクションのパラメーターで ビューがコントローラーに渡されることによって、理論的にはアクセスできます。
当然のことながら、ターゲット/アクション パラダイムはかなり制限されていますが、ここでのポイントは、「ユーザー インテントの単位」が確立されるまでビューがドラッグを追跡できることです。これは、処理のためにコントローラーにディスパッチできます。正確なメカニズムは、個々の望ましい動作のニーズによって決まります。