web-dev-qa-db-ja.com

MVCシステムはどのように機能しますか？

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

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

  • モデルはデータのみであり、データの変更を通知します。
  • ViewModelのメッセージを読み取り、ビューを更新します。
  • Controllerは、ユーザー入力をViewから読み取り、それに応じてモデルを変更します。

実装

  • モデル誰も知りません。
  • ビューはモデルを知っています。
  • ControllerはViewとModelの両方を認識します。

疑似コード：

/* 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. ViewがModelを直接変更できない理由はわかりませんが、コントローラーを使用する必要があります。
  3. アクションの後に実行するアニメーションがあるとします。誰がこのアニメーションを処理する必要がありますか：モデル、ビュー、またはコントローラー？また、アニメーションロジックはモデル、ビュー、またはコントローラーの一部ですか？詳細：ポーカーゲームを想定します。ユーザーがアクション（たとえば、「レイズ」）を選択した後、システムはアニメーションを再生する必要があります（たとえば、チップはプレーヤーのスポットからデスクに移動します）。このポーカーの例（アニメーション付き）をMVCとして表示するにはどうすればよいですか？それについて説明し、疑似コードを与えることはできますか？

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

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

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

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

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

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

コントローラー種類 "ビューを認識しています。"制御を指示するビューを認識していますが、何も認識していませんaboutそのビューです。また、以前にどのコントロールからどのビューが表示されたかもわかりません。コントローラはイベントに応答します。イベントはUIから受信され、何らかの状態情報（おそらくViewModel）を伝達し、モデル（ビジネスロジックが発生する場所）を介して論理制御を指示し、モデル（または形状が特定のビューに固有のデータの一部は、モデルおよびビューとは異なります。

ビューがモデルを直接変更できない理由はわかりませんが、コントローラーを使用する必要があります。

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

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

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

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

アクション（ "Raise"）はコントローラーイベントです。 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に応答する場合があります。エラーを示すビューがあり、その場合、そのビューは他の何かを表示します。）

26
David

単純なBankのアナロジーを使用します。

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

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

ランナーは、お金（データ）をバンカーからテラーに転送するために使用されます。

窓口係は顧客にお金を提示します。

簡単な表現：

モデル

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>
18
David East

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

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

あなたが殺す時間があり、ロバート・マーティンを聴いても構わないなら、彼は良いことをしました Ruby Midwest 2011 の基調講演）MVCに触れました。 1時間強ですが、かなり面白くて啓蒙的です。ほとんどの実装ではMVCが間違っているという彼の意見に従う傾向があります。少し時間をかけて周りを見て、最終的に、MVCを説明するためにリンクできる図を見つけました。 PopeとKrasnerから来たようなものです。

MVC
（ソース： as3dp.com ）

私の見解では、以下が重要なポイントです。

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

実際には、MVCはWebの世界に合わせて変更され、書き直されています。それはもはや実際にはMVCではないか、MVCが単に再定義されただけかもしれません。これが、MVCの非常に多くのさまざまな意見や表現が見られる理由です。デスクトップスタイルのアプリケーションの作成を検討している場合は、Krasner＆Popeの記事をご覧ください。 MVCがWebにどのように適用されるかを検討している場合は、Uncle Bobの基調講演でWebアプリケーションにより適した代替案を推奨します-彼がInteractor、Entity、Boundary Architectureより良い名前がないため。 "The Lost Years of Architecture"に関する彼の講演に関連するものを探してください。

9
D.Shawley