(A)Viewで画面やBGMなどの出力処理、Contorollerでキー入力やマウス入力などの入力処理をすると言った説明もあれば、
(B)Viewは入出力処理を行い、ControllerはViewとModelの橋渡し役であると言った説明もある気がします。
MVCの実装は「必ずこうでなければならない」という程厳格なものではないのが説明に若干のブレを生じている理由だと思います。
SmallTalkでの例がwikipediaに載っていますね。これを見るとSmallTalkではマウスやキーボードのイベントは画面上へのGUI表現を担うViewクラスではなくControllerクラスに配送される仕組みであることが伺えます。最初にMVCが提唱されたのがSmallTalkだったので元々こうした仕組みのことを指していたのだろうと思います。
Javaのswing/JavaFXのクラスの機能を概観すると似た雰囲気ですが若干見え方が違うように感じる部分もあります。イベントは普通Controllerが受け取るのではなく「View内部へ自動的に通知される」仕組みに見えます。これは単にSmallTalkの仕組み「イベントをControllerで受け取りViewとやりとりしながらGUIへの反映をする」という若干複雑な制御をするよりは「Viewが典型的なイベントの制御をある程度やった上でアプリケーションプログラマーが興味を持つようなコールバックをControllerに対して行う方が簡潔な設計になる」という理由なのだと思います。
ViewとControllerはSmallTalkで言えば(A)になるでしょうし、Javaのswing/JavaFXに当てはめると(B)のような説明の方が感覚的に一致するでしょう。
ではSmallTalkとJavaではMVCは全然違うものかといえば、そうでもなく以下のようなMVCの概念を用いると本質的な課題を解決するための手段と捉えることができると思います。ここでいう課題とは「画面を表現するコードと何か起こったとき画面やデータを変更する設計が入り混じってしまい複雑すぎて初期設計や設計変更が大変」を指します。
画面上の表現やGUI操作仕様とは独立して設計しViewやControllerを置き換えても依然として有用な抽象的なデータ機能を持つように設計しよう
画面上への表現を担うことが主たる役割。アプリケーション独自の論理を入れこまないようにすることで機能をとらえやすくし、Modelの設計変更をしなくても見た目だけを独立に設計・変更できるようにしよう。
ModelとViewをアプリケーションが行うべき振る舞いとなるように「しかるべき制御を行う」もの。ここはアプリケーションごとに作るのはしかたない。(アプリケーション間で流用できる共通的な制御もなくはないと思います。そうした場合はViewと合わせてカスタムコントロールとして部品化できる場合もあると思います。そうなると最早ControllerではなくViewの一部になる気がします)
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。