21

私はMVCパターンを学習しようとしていますが、場所ごとに異なることを言っています。だから今、私は本当のMVCが何であるかわかりません。

だから私はその最も純粋なMVCを推測しています：

  • モデルは単なるデータであり、データの変更を通知します。
  • ビューはモデルのメッセージを読み取り、ビューを更新します。
  • コントローラは、ビューからユーザー入力を読み取り、それに応じてモデルを変更します。

実装

  • モデルは誰も知りません。
  • ビューはモデルを知っています。
  • コントローラはビ​​ューとモデルの両方を認識しています。

擬似コード：

/* Model */
class Color{ 
  color = blue;
  setColor(color);
  notifyUpdate();
}
/* View */
class ColorPicker(model){
  model.register(update);
  update(){
    this.colorToExhibit = model.color;
  }
}
/* Controller */
class Colorize(view, model){
  view.register(update);
  update(color){
    model.setColor(color);
  }
}

いくつかの質問：

  1. そうですか？
  2. ビューがモデルを直接変更できない理由はわかりませんが、コントローラーを介して変更できます。
  3. アクションの後に実行するアニメーションがあるとします。このアニメーションを処理する必要があるのは、モデル、ビュー、またはコントローラーの誰ですか？また、アニメーションロジックはモデル、ビュー、またはコントローラーの一部ですか？詳細：ポーカーゲームを考えてみましょう。ユーザーがアクション（たとえば、「レイズ」）を選択した後、システムはアニメーションを再生する必要があります（たとえば、チップがプレーヤーのスポットからデスクに移動します）。このポーカーの例（アニメーション付き）をMVCとしてどのように見ることができますか？それについて説明し、擬似コードを与えることができますか？

ありがとうございました。

4

3 に答える 3

26
  • モデルは単なるデータであり、データの変更を通知します。
  • ビューはモデルのメッセージを読み取り、ビューを更新します。
  • コントローラは、ビューからユーザー入力を読み取り、それに応じてモデルを変更します。

モデルは単なるデータではありません。モデルはビジネスロジックでもあります。これには、システムのすべてのインテリジェンス、または少なくとも舞台裏のインテリジェンス（データベース呼び出しやその他のサービス呼び出しなど）の抽象化が含まれています。「モデルを重くし、コントローラーを軽くしてください」ということわざを考えてみてください。

  • モデルは誰も知りません。
  • ビューはモデルを知っています。
  • コントローラは、ビューとモデルの両方を認識しています。

モデルは、それが正しいことを誰も知りません。モデルはアプリケーション間で移植可能である必要があり、UIの懸念にまったく依存しないようにする必要があります。（この場合、ビューとコントローラーはUIの問題です。）

ビューはモデルを認識しており、これも正しいです。ビューは基本的にモデルに「バインド」されます。すべてのUI要素を表示し、それに応じてモデルデータをUI要素内に配置します。

コントローラは「ビューを知っている」ようなものです。どのビューに直接制御するかはわかりますが、そのビューについては何も知りません。また、以前にどのコントロールからどのビューが来たのかもわかりません。コントローラはイベントに応答します。イベントはUIから着信し、ある種の状態情報（おそらく、ViewModel）を運び、モデル（ビジネスロジックが発生する場所）を介して論理制御を指示し、モデル（または形状の場合はViewModel）で応答します。特定のビューに固有のデータは、モデルとは異なります）およびビュー。

ビューがモデルを直接変更できない理由はわかりませんが、コントローラーを介して変更できます。

ビューは、ユーザーインタラクションのコンテキスト内でモデルを操作できますが、これらの変更が何らかの形で持続することを期待するべきではありません。ビューは「クライアント側」と見なされるべきであり、「サーバー側」については何も知りません。（Webアプリケーションではなく、ネイティブアプリケーションについて話している場合でも。）変更を永続化することは、UIの「アクション」または「イベント」と見なされ、コントローラーに送信されます。

アクションの後に実行するアニメーションがあるとします。このアニメーションを処理する必要があるのは、モデル、ビュー、またはコントローラーの誰ですか？また、アニメーションロジックはモデル、ビュー、またはコントローラーの一部ですか？

アニメーションは、完全にUIベースの操作のように聞こえます。ビュー内にあります。UIアニメーション以外にも起こっていることはありますか？アニメーションはバックエンドで何かを変更しますか？たとえば、Webアプリケーションがあり、ページが読み込まれたときに、一部のデータ（アニメーション）をフェードインしたい場合...それは完全にビューにあります。データは他のデータと同じようにビューに配信され、アニメーションは完全にUI（ビュー）内で行われます。モデルまたはコントローラーの観点からは何もしません。

ポーカーゲームを考えてみましょう。ユーザーがアクション（たとえば、「レイズ」）を選択した後、システムはアニメーションを再生する必要があります（たとえば、チップがプレーヤーのスポットからデスクに移動します）。このポーカーの例（アニメーション付き）をMVCとしてどのように見ることができますか？それについて説明し、擬似コードを与えることができますか？

アクション（「レイズ」）はコントローラーイベントです。UIはコントローラーに接続して、「レイズ」を実行します。したがって、コントローラーには次のようなメソッドがあります。

View Raise(GameState state)
{
    // Interact with the Models to update the known state of the game.
    // The Models would perform the actual Poker game logic.
    // Respond with a View bound to updated Models.
}

コントローラが新しいビューでUIに応答すると、そのビューにはユーザーに表示するアニメーションが含まれます。（結局のところ、アクションが成功しない限り、アニメーションを実行したくないでしょう？コントローラーが成功したアクションを示す新しいビューでUIに応答すると、アニメーションが再生されます。代わりに、UIに応答する場合があります。ビューがエラーを示している場合、そのビューには別の何かが表示されます。）

于 2012-05-27T13:41:34.997 に答える
18

単純な銀行の例えで行きます。

  • テラーはビューです。
  • ランナーはコントローラーです。
  • 銀行家はモデルです。

銀行家は賢い人であり、彼らはすべてのビジネスロジックを知っており、すべての複雑な計算を行います。

ランナーは、銀行員から出納係にお金（データ）を輸送するために使用されます。

テラーは顧客にお金を提示します。

簡単な表現：

モデル

public class BankAccount
{
     public int ID;
     public int Balance;

     public BankAccount(int id)
     {
         ID = id;
         Balance = DetermineAmount();
     }

     public int DetermineAmount()
     {
         // Gather transaction info, debits, credits and return a
         // sum of the amount left in the account depending on the
         // id provided.
     }
}

コントローラ

    public class BankAccountController
    {

         public ViewResult Index(int id)
         {
             BankAccount account = new BankAccount(id);
             return View(account);
         }

    }

意見

<ul id="account-info">
   <li>Account ID: `@Model.ID`</li>    
   <li>Balance: `@Model.Balance`</li>
</ul>
于 2012-05-27T14:57:39.300 に答える
9

歴史的な真のMVCに興味がある場合は、TrygveReenskaugから始めてください。彼は1970年代後半にそれを作成しました（観察されましたか？、カタログ化されましたか??）。まず、1979年の「Models-Views-Controllers」をお読みください。用語を定義しています。タイトルに注意してください。3つの役割はすべて複数形です。これは、ほとんどの人が間違っているように見える最初のことです。

MVCの最初の使用法について私が見つけた最も良い説明は、実際には「InsideSmalltalkMVC」というタイトルの2004年のプレゼンテーションにあります。Smalltalk 80の最終バージョンのMVCを説明している標準的な論文は、Krasner＆Popeの「Smalltalk-80でModel-View-Controllerユーザーインターフェイスパラダイムを使用するためのクックブック」とSteveBurbeckの「Smalltalk-80でのアプリケーションプログラミング」だと思います。 ：Model-View-Controller（MVC）の使用方法」。どちらの論文も読む価値があります。

殺す時間があり、Robert Martinの話を聞いてもかまわない場合は、RubyMidwest2011でMVCに触れた良い基調講演を行いました。それは1時間強ですが、非常に面白くて啓発的です。私は、ほとんどの実装でMVCが間違っているという彼の意見に従う傾向があります。少し時間をかけて見て回ったところ、MVCを説明するリンク可能な図がついに見つかりました。私が好きなのは教皇とクラスナーから来ました。

MVC
（出典：as3dp.com）

私の観点から、以下は重要なポイントです。

  • モデルインスタンスは、関心のあるオブジェクトに変更を通知する責任があります。これらは任意のオブジェクトインスタンスである可能性があることに注意してください。この図は、ここで更新を受信するビューとコントローラーの両方を示しています。
  • ビューは、現在の状態を照会し、結果を表示する役割を果たします。通常、フィルタリングまたはデータ変換も実行します。
  • コントローラは、ユーザー入力を受け入れ、ビューメッセージをビューに転送する責任があります。
    • メッセージの表示はMVCの一般的なテーマです。これらはUIの世界から独立していることが重要です。これらはマウスクリックではなく、ビュー固有のイベント言語です。これは私たちを次のポイントに導きます。
  • ビューは、コントローラーにまったく依存しません。コントローラは、ビューの配置と作成、およびその他の世界とビューの間のインターフェイスの提供を担当します。
  • 完璧な世界では、ビューはモデル表現を表示する役割を果たします。これは、MVCがデスクトップアプリケーションに適用されたときの仕組みです。

現実には、MVCはWebの世界のためにひねられ、書き直されています。それはもはや実際にはMVCではないか、MVCが単に再定義されただけかもしれません。これが、MVCのさまざまな意見や表現が世の中に出回っている理由です。デスクトップスタイルのアプリケーションの作成を検討している場合は、Krasner＆Popeによるものをご覧ください。MVCがWebにどのように適用されるかを検討している場合は、ボブおじさんの基調講演をお勧めします。これは、Webアプリケーションにより適した代替案であり、名前が不足しているため、彼はInteractor、Entity、BoundaryArchitectureと呼んでいます。「失われた建築の年」についての彼の話に関連するものを探し回ってください。

于 2012-05-27T14:39:57.307 に答える