まずあなたの環境について
プログラミングの講師がいるのであれば講師をガンガン使うべきですし、講師が自分で考えろというのであれば、講師を変えたほうがいいです。
まず、第一に質問しても答えをくれないという学習環境が劣悪です。
学校で数学の質問しに行って自分で考えろなんていう教師いますか。居残りしてでも学ぶべきです。
そして、講師にお金を払っているのであれば自分で考えるだけの時間にお金を払っているわけなのだからお金の無駄でもあります。
自分で考えろなんて素人でも言えますし、質問が沸くというのは講義の内容が不十分だからです。質問するだけで課金のようなものを要求されるのであれば別の環境を探してみる方がよいと思います。
MVCという前提
@Vercleneさんの回答の通りではありますが、@Vercleneさんの回答に返信がないのでどういう状況なのかよくわかりません。
MVCやMVVMというアーキテクチャ構成について
まず、
ResetGameメソッド内のController.ResetGameData()はViewがControllerを直接操作してしまっている（MVCに反する）ことになるのでしょうか？
という質問の意図としてはなんなのでしょうか？単に当てはめることに着目しているだけ。。。？
MVCなどの考え方に当てはめる一つの命題としては単体テストを可能にすることです。
簡単な話Resetがどこにあろうが、単体テスト可能なので関数としてviewにあろうがcontrollerにあろうが、別のところに単体の関数としてあろうがテスト可能なのでどこでもよくはあります。
アーキテクチャ構成を考えるとき、単体テスト可能性と役割を考えるとレイヤーは自然と構築できますので、MVCやMVVMはデータフローの問題でしかなくなります。
普通Modelといえばデータベーステーブルのスキーマを指すフレームワークが多いですが、
テーブルに対する取得処理、保存処理をModelに入れると役割(責任)があいまいになります。
なので、普通はRepositoryクラスを用意しようとなります。
Repositoryクラスは当然Modelに問い合わせを行うので依存関係がありますが、単体で取得処理ができてるか？このデータを保存できるのか？のテストが可能です。
何が言いたいかというとMVCやMVVMは構成要素を決めるものではなくデータフローの話だということです。RepositoryクラスはMVCやMVVMともに採用するのが普通ですが、この名前にRなんて含まれていません。
構成としての妥当な設計
上記の点を踏まえてどのような単体要素が必要なのかを改めて考えてみましょう。
Viewに対してしたいテストはある条件の時にUI要素が表示されているか、Disabled化されているかどうかなどです。
UIのレンダリングが責務ですので、オセロのデータを実際に管理するのは別です。
Viewとして、開始時、プレイ時、終了時というUI要素をそれぞれ用意することも考えられますし、抽象化して一つの画面として定義することも可能です。
オセロを行う上ではボードや石というクラスが必要で、
viewはボードの内部状態によってレンダリングできるべきです。
そうすればボードが正常にデータの部分だけに集中して石をおけるか？の単体テストが行えます。
ボードクラスにはtoViewDataなど、オセロのボード上のViewに表示するメソッドが考えられ、インタフェースとして実装するのもよいでしょう。
ログに書き込むためのメソッドなどがあってもよいでしょう。
MVCの流れ
MVCはcontrollerがすべて指示を出します。viewにこのデータを渡すので表示してください！とかModelにこのデータください！とか、このデータ保存してください！とか。
なので、ボードというクラスはコントローラで管理するなど行い、Viewに伝えて、Viewはこのデータがきたらこう表示するということに専念するのが無難な設計です。
その際、ResetGameDataみたいな動的な状態をViewに伝えるのは不自然なので、
NewGameなどのメソッドを作り、「新規画面を表示するためのプロセス」であると考えましょう。そうすれば新しいボードをviewに返す、だとかviewで開始状態のものを表示するということが可能になります。
進行中を表す、ProcessingGameを作り引数を受け取り適切な処理を追加しviewを描画するということも必要です。
Viewは常に新しいインスタンスをコンストラクタを介して作成してもいいでしょうし、データを部分的に変えるだけのメソッドを公開してもよいです。
MVVMではどうか？
MVVMではControllerがViewに指示を出すのとは対照的に、ViewModelというデータホルダーが存在し、どのViewでもViewModelを使用できます。
Viewが必要なViewModelを使うという流れのためMVCとは逆です。
そもそもとしてMVVMのようなアーキテクチャは前述したようにデータの流れであるため厳な意味で責任がControllerとViewModelでは異なりますが、
ViewModelは単体で存在し、Viewも単体で存在するため結合度が低くなります。
まとめ
これらの構成要素は依存性が少なくテスト可能であることを重点におくと関数型プログラミングの基本的な概念、純粋関数の理解などが必要になってきます。
そのためオブジェクト指向を学んだばかりの初学者にとって無難な設計は非常に困難です。
特にオブジェクト指向は自由度が高く様々な責任を持たせられますので、初学者が妥当な設計をするのはまず不可能でしょう。
今回の要件でいえば、オブジェクト指向のメソッドにはデータを取得するためのqueryと内部状態を変更するためのcommandがあるという点を抑えておくと思考の整理の役に立つかもしれません。
