1

説明された方法は、イベントとパブリッシュ/サブスクライブモデルの使用によるものでした。基本的に、モデルは単なるデータであり、ビュー/ GUI/UIの知識はありません。モデルは通常、そのデータを操作し、操作などを実行できる単なる抽象オブジェクトです。

ビューは、モデルの変更に応答し、通常はこのデータをユーザーに表示する別のクラスです。以前は、ビューとモデルを結合せずにこれがどのように発生するかはわかりませんでしたが、イベントで説明すると、混乱が大きくなります。これは、モデルに、何か面白いことが起こったときにそれ自体が発生する公開イベントが含まれていることを意味しますか？たとえば、チェスのゲームをプログラミングしている場合、ピースが移動されると、モデルはPieceMoved必要な情報（どのピース、どこからどこに移動したかなど）を使用してイベントを発生させ、ビューはそのような情報をサブスクライブできます。イベントを実行してから、古い正方形から新しい正方形に移動するピースのアニメーションを表示します。

それでも私を混乱させる部分は、コントローラーの正確な性質です。モデルとビューに新しい情報がどのように提供されるかを理解するのに苦労しています。コントローラにモデルとビューへの参照が含まれていると思います。チェスの例を続けると、コントローラーはユーザー入力に応答して（たとえば、ピースを移動するために）、モデルにどのピースをどこに移動したいかを提案しますか？次に、モデルはこの情報を取得し、それが正当な動きであるかどうかを確認します。正当な動きである場合は、それに応じてモデルを更新し、それに応じPieceMovedてビューが反応してグラフィカルレルムを更新するイベントを発生させますか？

最後に、コントローラーはどのピースが動かされようとしているのかをどのように見つけますか？そのタイプのものはビューに深く関係しているようです（たとえば、移動には、最初に移動したい部分をクリックしてから、目的の正方形をクリックする必要があります）。コントローラがマウスクリックに応答してそれらの座標をモデルに送信すると想像しますが、モデルはこれらの座標を変換してどのピースが選択されたかを見つける方法をどのように知るのでしょうか？それはビューに深く関係していませんか？ビューは、モデルとコントローラーに単に応答するのではなく、何らかのロジック処理を実行する必要があるように見えますが、その場合、ビューは適切なビューではなくなります（ビューとモデルの組み合わせではありません）。

4

4 に答える 4

0

MVC はかなり一般的な概念です。さまざまな方法で実装されており、それらのほとんどには何らかの妥協点があります。

私が見る問題は、あなたが難解な概念を取り、それに具体的な実装の詳細を適用しようとしているということです。非常に具体的な実装 (asp.net MVC、fubuMVC、spring MVC、smalltalk MVC など) を念頭に置いて、それぞれが通知やイベント処理などを異なる方法で実現しない限り、これを行うのは困難です。

MVC の概念について話しているだけの場合は、MVC の概念を一般的な方法で扱う必要があります。具体的な実装があれば理解しやすいかもしれませんが、実装の理解に基づいてパターンを理解する (MVC) という道をたどることになるため、パターン自体の理解がゆがむ可能性があります。

したがって、メッセージやイベントについて読むときは、「実装で定義された何らかのメカニズム」を考える必要があります。それはコールバックかもしれないし、C# イベントかもしれないし、Windows メッセージかもしれないし、強制を使っているかもしれない;)

編集：

あなたの更新に関して、私は繰り返します。一般的な概念に関する実装固有の詳細に回答することはできません。それらの実装の詳細がどのように達成されるかを誰かが教えてくれるようにするには、特定の実装を定義する必要があります。

于 2012-09-06T21:48:53.840 に答える
0

主に非常に多くの異なる MVC フレームワークがあるため、この質問には多くの答えがあります。いくつかの例については、http://martinfowler.com/eaaDev/uiArchs.htmlをご覧ください。これは主に私が最近取り組んでいるものであるため、MVVM の観点から説明することもできます。これが私の考えです。

モデル層は、基本的にデータとビジネス ロジックです。ここでは、データベースまたは Web サービスと話している可能性があります。システムを作成することになった場合、それは単なる GUI ではなく、再利用可能なコードです。

ViewModel は Model の上にあり、基本的にデータをプロパティとして (エヘム) 表示します。INotifyPropertyChanged インターフェイスを使用して、データが変更されたときに UI に通知します。モデルレイヤーにプッシュする前に何かを構築するために使用しているデータがある場合、それはここに存在します。通常、UI で実行できるアクションは ICommnands として公開します。

ビューレイヤーは、バインディングを使用してビューモデルに接続するだけなので、結合が最も少なくなります。視覚化するものは、そのフォームを変更するために使用されるオプションの IValueConverters にバインドされているプロパティです。

Visibilty="{Binding IsVisible, Converter={StaticResource booleanToVisibiltyConverter}}"

アクション UI 要素は、ViewModel のコマンドにバインドされ、ViewModel アクションを開始します。

Command="{Binding DoSomething}"
于 2012-09-06T22:10:38.590 に答える
0

MVC パターンの悪い点は次のとおりです。

  • 誰もが自分のバージョンを持っています
  • 最初に把握するのは少し抽象的です

良い点:

  • それは実際にはかなり単純です
  • これは、ほとんどのアプリケーションを分割する素晴らしい方法です

ただし、質問に答えるには：

モデル

これは簡単です。モデルは自分自身についてのみ知っている必要があります。それはゲームの盤であり、駒であり、ルールです。デスクトップ アプリケーションまたは Web アプリケーションでモデルを再利用できれば、モデルを正しく構築していることがわかります。

景色

これも複雑ではありません。これは視覚的な部分であり、ユーザー入力を処理する部分です。MVC パターンにおけるビューの役割を理解するための最も重要な概念は、ビューがシステムのパブリック インターフェイスを呼び出す方法を提供する必要があるということです。チェスゲームでは、要素を描画し、ユーザーがマウス/キーボードで何をしているかを検出する必要があります。ユーザーが何かを行うとき、システムを呼び出す責任があるのはビューです。「ユーザー 1 がピースを X から Y に移動したい」 (重要: ほとんどの場合、ユーザー 1 が座標 x、y でクリックしたような呼び出しをビューにトリガーさせたくありません。ピクセルはビューの領域です。システムはグラフィック表示方法に関係なく注文を受けます)。

コントローラー

そうです、これはそれほど単純ではありません。コントローラーは、システムへのパブリック インターフェイスへの呼び出しを処理する必要があるコントローラーです。あなたの例では、「User1はXからYに移動します」という呼び出しを受け取り、モデルの適切なオブジェクト（この場合はボードである可能性が非常に高い）でメソッドを呼び出します。したがって、コントローラーはモデル内のオブジェクトについて完全に認識しています。ただし、アプリケーションに必要であるがモデルのドメインに属さないコードを含めることもできます。ユーザーがシステムにアクセスする権限を持っているかどうかを確認する必要がありますか? その呼び出しをファイルに記録する必要がありますか? ほとんどの場合、そのようなものはコントローラーに入ります。

ただし、これは MVC の私独自のバージョンにすぎません (私も、他のみんなと同じように、独自のバージョンも持っています... :)

于 2012-09-06T22:24:40.663 に答える
-1

したがって、ビュー (チェス盤) とチェス盤のコントローラーがある場合、コントローラーはそのイベントを格納します。駒を動かすと、PieceMoved現在の位置や目的の位置などの情報をこのイベントに渡すイベントが発生します。

非常に単純なアプリケーションの場合、モデルの概念を理解できない場合があります。複数のビュー (詳細ビューや作成ビューなど) で再利用できる請求モデルがある場合があります。必要になるたびにこのコードを複製するのは望ましくないため、コントローラーでは、各イベントがそれを必要とする課金モデルにアクセスします。モデルを作成することで、コードをカプセル化しています。

于 2012-09-06T21:54:58.537 に答える