1

ここに私の考えがあります: MVC を使用する目的は、関心の分離と GUI ロジックのテスト可能性です。ビューはさまざまなモデルで機能し、モデルはさまざまなビューで機能できる必要があります。

コントローラークラスは、モック/テストの理由からインターフェイスを実装する必要があり、ビューはこのインターフェイスを介してコントローラーメソッドを呼び出す必要があると思います。しかしそうすると、ビュー要素（テキストボックス、グリッドなど）をコントローラーで処理するのが難しくなります。したがって、これらの要素は、何らかの方法でコントローラーによって認識される必要があります。

1. インターフェイスを通じてこれらの GUI 要素を公開していますか? コントローラーがGUI要素を直接処理できるように、コントローラークラスを部分クラスとして定義しますか（インターフェイスはどうなりますか）？この問題を解決するために何をしますか?

2. 基本的に、コントローラーは複数のインターフェースを実装する必要がありますか? 1つはビュー用、もう1つはモデルレイヤー用で、ビュー/モデルがコントローラーを介して異なるモデル/ビューで動作できるようにしますか?

3. モデル層もモック/テスト用のインターフェースを実装する必要がありますか?

テスト、疎結合、SoC の目的を最適に達成するにはどうすればよいでしょうか? あなたの経験/考えを共有してください。

4

2 に答える 2

1

ビューはインターフェイスを実装し、通常はコンストラクターを介してコントローラーに渡される必要があると思います。このようにして、コントローラーはビューインターフェイスのフィールドを使用して、ビューが使用するコントロールの値を取得できます。また、選択した任意のモデルを使用できます。これにより、必要なモデルとビューの間の緩い結合が得られます。

モデルのリポジトリをコンストラクターを介して渡すことにより、モデルに対して同じことを行うことができます。リポジトリメソッドは、モデルクラスが実装する必要のあるインターフェイスを返す可能性があります。

次に、コントローラーにインターフェイスを実装させ、実行時にIoCコンテナーを使用して適切なコントローラーを取得できます（これにより、コントローラーに適切なビューとモデルリポジトリが自動的に提供されます。これにより、コントローラーを簡単に交換して、別のビューとモデルの現在の組み合わせ。ただし、ビューのタイプ（ビューインターフェイス）ごとにコントローラーが1つしかないため、一般的にはこれは不要です。

于 2008-09-28T12:52:43.990 に答える
1

guiに数百の要素がある場合、インターフェースを介してGUI要素を公開することは長い作業になる可能性があります。しかし、別のオプションがわかりません。部分的なクラス化により、GUIロジックのテストが難しくなり、MVCの基本も台無しになります。したがって、処理される要素をメソッドのパラメーターとして渡すことができます。これにより、コーディングの量を減らすことができます。

于 2008-09-28T13:09:15.293 に答える