適切なModel-View -_____デザイン

モデルビューコントローラー、モデルビュープレゼンター、モデルビューViewModelなどについて読んでいますが、一般的に、基本的な概念は非常に理解しやすいようです。可能。デザインチョコレートにロジックピーナッツバターは含まれていません。クール、私はそれが好きです。

問題は、その3番目の部分についてはまだ少し曖昧だということです...モデルまたはビューではありません。誰もがそれを何と呼ぶべきか、何をすべきか、何が適切で、何が間違っているのか、自分の考えを持っているようです...それはプレゼンターの仕事だからです。

私はとりとめのないです。

それらの違いを誰かに説明するように頼むのではなく、すでに何度も行われているので（私は知っています;数え切れないほど多くの記事を読んでいます）-私は私は自分でモデルを作った少数のプログラマーです。

そうは言っても、このデザインをどのように分類しますか？そしておそらくもっと重要なことですが、これについて明らかに悪いことはありますか？確かに、これが本当に堅実な設計であれば、私は良いことをしていると聞きたいと思いますが、賞賛よりもむしろ堅実なアドバイスを与えられるでしょう。

注：Model-View-の神秘的な3番目の部分に「ブリッジ」を使用しますか？それが「すべき」であるという潜在意識の提案を避けるため。

モデル

• データに対する権限です。
• リクエストされた変更に関する情報をブリッジから受け取ります。
• データが他のデータにどのように関連するかについてのすべてのロジックを含み、実行します。
• データが変更されたときにブリッジに通知します（ブリッジが関心を示したデータについて）。表現の編集：外部のサブスクライバー（何も知らない）が、その状態または計算結果をモニターできるようにします。
• ビューに関する知識がありません。

見る

• ユーザーにデータを表示および操作する方法を提供することに関心があります。
• ブリッジからデータ更新に関する情報を受け取ります。
• ユーザーにデータとコントロールを提示する方法のすべてのロジックを含み、実行します。
• ユーザーがモデルに（おそらく）影響を与えるアクションを実行したときに、ブリッジに通知します。
• 興味のある情報をブリッジに通知します。
• モデルに関する知識がありません。

ブリッジ

• モデルとビューの間のコーディネーターおよびトランスレーターです。
• モデルとビューの間で受け渡される情報に適切なフォーマット変更を加えます。
• 「誰が何を知る必要があるか」に関する情報を保持します。
• モデルとビューの両方の知識がある。

その他の注意事項

• より複雑なプログラムでは、複数のモデルが存在するのが一般的です。この状況では、ブリッジは通常、複数のモデル間の調整/翻訳の仕事を引き受けるため、protocall / API / designモデルの構築対象の権限になります。（たとえば、カードゲームプログラムを構築し、代替のデッキシャッフルモデルを構築する場合、ブリッジを使用して、ブリッジとの適切な通信に必要な機能を決定する必要があります。）
• ビューとモデルが1つだけの小さな単純なプログラムでは、ブリッジがどちらの側でどの機能を使用できるかを「想定」するのが一般的です。ただし、プログラムがより複雑になると、非効率性とバグのある仮定を回避できるように、ビューとモデルが機能をブリッジに報告することをお勧めします。

ほぼカバーしていると思います。どうしても、私が使用する傾向のあるデザインについて質問がある場合は歓迎します。また、提案をお勧めします。

そしていつものように、お時間をいただきありがとうございます。

あなたのフレーズ

「モデルとビューの間のコーディネーターおよびトランスレーターです。」

ブリッジがMVPアーキテクチャのプレゼンターであることを示します。

MVPとMVCは非常に似ていますが、MVPではプレゼンターのみがモデルを観察し、MVCではビューはモデルを直接観察することもできます（プレゼンターを「ブリッジ」として使用することはできません）。

モデルの責任

「データが変更されたときにブリッジに通知します（ブリッジが関心を示したデータの場合）。」

おそらく不十分な言い回しまたは間違いです。モデルがBridge / Presenter / ControllerまたはViewのいずれかに依存することは望ましくありません。代わりに、オブザーバーパターン、イベント、またはリアクティブプログラミングを使用して、ブリッジがモデルの変更をサブスクライブできるようにします。そして、あなたはあなたの責任を次のように言い換えることができます：

「外部のサブスクライバー（何も知らない）がその状態または計算結果をモニターすることを許可します。」

モデルがコントローラーまたはビューに依存していない場合、テストが簡単になり、移植性が大幅に向上します。

あなたを混乱させていることの1つは、2つのまったく異なるパターンがあり、どちらも一般にmodel-view-controllerと呼ばれることです。

smalltalkで実装され、ローカルguiシステムに役立つオリジナルがあり、web-mvcと考える傾向があるものがあります。これは、コントローラがクライアント上にあるビュー（おそらくレンダリングされたhtmlとして、またはajaxを介して）。

あなたの説明は、web-mvcのほとんどの定義に収まるように聞こえます。

プログラミングコミュニティでは、この正確な命名法について多くの議論があります。誰もが何についても同意するようには見えません。

私にとって、ブリッジがビューにどのように接続されているかによって、名前が決まります。

• ブリッジごとにビューのコレクションがある場合、ブリッジはコントローラーです。
• ブリッジごとに常に1つのビューがある場合、ブリッジはプレゼンターです。
• ビューごとにブリッジのコレクションが存在する場合、ブリッジはビューモデルです。

時には物事はそれほど明確ではありません。たとえば、プレゼンターを複数のサブビューで構成される複合ビューに接続したり、ビューの知識がなくてもコントローラーを作成したりできます。それにもかかわらず、私のルールは良いスタートだと思います。

副次的な注意事項として、私はこのような責任を組み合わせたいと思います。

モデル

主な責任：データの永続化
副次的な役割：更新の検証、更新のオブザーバーへの通知

見る

主な責任：データの提示
副次的な役割：入力の受け入れ、UXの提示

ブリッジ

主な責任：データの更新
副次的な役割：入力のクリーンアップ、データとビューの同期

提案されたパターンは表面上は正しいように見え、小さなインスタンスでは間違いなく機能しますが、アプリがより複雑になると、何が何を更新し、誰が何を聴いて、なぜしようとしているのかがわからないという問題に直面します非常に多くのビュー内から、非常に多くのモデルを制御するために、誰もが互いにアクセスする必要がある、など。

次のパターンを使用してアイデアを拡張することをお勧めします（Amy PalamountainのトークEnemy of the Stateから引用）。

モデル

• 状態をデータストアと同期する
• 新規/更新データの検証を処理します
• 状態が変化したときにイベントを発生させる

視聴回数

• レンダリングテンプレート
• モデルイベントの処理
• DOMイベントを処理する
• モデルとDOM間の相互作用を仲介します

コントローラー

• 最大2つのモデルとビューを管理します
• コンテナ内のビューを追跡します

モジュール

• コントローラーとそのビューとモデルの論理的なグループ化
• テスト可能
• 小さくて維持可能（単一の責任）
• （コントローラーを介して）含まれているビューとモデルの状態とイベントを調整します
• 独自のビューを自由に表示
• ビューを表示する場所を自由に選択できない

レイアウトマネージャー

• レイアウトの構成を担当
• モジュールがコンテンツを表示できる領域を備えたDOMのアプリケーションシェルを定義します

発車係

• イベントをリッスンします（グローバルなPubSubストリームを介して）
• イベントに基づいて新しいモジュールをロードする責任があります
• ロードされたモジュールをレイアウトマネージャーに渡す
• モジュールのライフタイム全体を作成します（作成、クリーンアップ、キャッシュなど）
• イベントの例：
  • ルート変更（初期ロードルートを含む）
  • ユーザーインタラクション
  • サーバー側の状態変更などにより、モデルイベントからバブルされたモジュールイベント

応用

• 全体的なセットアップを担当し、次のようなインスタンスを作成します。
  • 発車係
  • ルーター
  • PubSubストリーム
  • ロガー
  • 等

この種のパターンにより、アプリケーションの構成、単体テスト、Bridgeが時間の経過とともに構築する複雑さの解消、懸念事項の分離などが可能になります。

Amyが指摘するように、クライアント上にサーバーを構築しないように注意してください。そして、「私はMV *フレームワークを作成しているので、私は___！」という教義に陥らないように注意してください。代わりに、これらすべてのアイデア（および他の回答）を使用して、アプリケーションおよびチームに最適なものを見つけてください。

Amy Palamountainの講演Enemy of the State（これらのアイデアの出所）を見るか、少なくとも講演のスライドを確認することを強くお勧めします。