適切なモデル-ビュー-_____設計
私はモデルビューコントローラー、モデルビュープレゼンター、モデルビュービューモデルなどについて読んでいますが、一般的に、基本的な概念は非常に理解しやすいように見えます。可能。デザインチョコレートにロジックピーナッツバターを入れないでください。かっこいい.
問題は、その3番目の部分についてはまだ少し曖昧だということです...モデルでもビューでもない部分です。誰もがそれを何と呼ぶべきか、何をすべきか、何が適切で、何が間違っているのかについて独自の考えを持っているようです...そして、プレゼンターがいつビューモデルになるのか、そしてビューがいつなのかを理解しようとしています。それはプレゼンターの仕事であり、-
私はとりとめています。
それらの違いを誰かに説明するように依頼するのではなく、それはすでに何度も行われているためです（私は知っています。私は数えることができるよりも多くの記事を読んでいます）-の考えを聞きたいと思います私が一緒に石畳を作ったモデルのプログラマはほとんどいません。
とは言っても、このデザインをどのように分類しますかそしておそらくもっと重要なことはこれについて明らかに悪いことはありますか？確かに、私は聞きたいですこれが本当に堅実なデザインである場合は良いことをしますが、賞賛よりも堅実なアドバイスを与えられたいと思います。
注：Model-View-の不思議な3番目の部分には「ブリッジ」を使用しますか？ 「どうあるべきか」について潜在意識的な提案を回避するため。
型番
- データに対する権限です。
- ブリッジから要求された変更に関する情報を受け取ります。
- データが他のデータとどのように関連するかについてのすべてのロジックを含み、実行します。
データが変更されたときにBridgeに通知します（Bridgeが関心を示したデータの場合）。言い回しの編集：外部サブスクライバー（何も知らない）が状態または計算結果を監視できるようにします。- ビューについての知識がありません。
見る
- ユーザーにデータを表示および操作する方法を提供することに関係しています。
- Bridgeからデータ更新に関する情報を受け取ります。
- データとコントロールをユーザーに提示する方法に関するすべてのロジックを含み、実行します。
- ユーザーがモデルに（おそらく）影響を与えるアクションを実行したときに、ブリッジに通知します。
- どの情報に関心があるかをBridgeに通知します。
- モデルについての知識がない。
ブリッジ
- モデルとビューの間のコーディネーターとトランスレーターです。
- モデルとビューの間で受け渡される情報に適切なフォーマット変更を加えます。
- 「誰が何を知る必要があるか」に関する情報を保持します。
- モデルとビューの両方の知識がある。
その他の注意事項
- より複雑なプログラムでは、複数のモデルが存在するのが一般的です。この状況では、ブリッジは通常、複数のモデル間の調整/変換の仕事を引き受け、したがって、プロトコール/ API /設計モデルをどのように構築するかに関する権限になります。 （たとえば、カードゲームプログラムを作成していて、別のデッキシャッフルモデルを作成したい場合は、ブリッジを使用して、ブリッジと適切に通信するために必要な機能を決定する必要があります。）
- ビューとモデルが1つだけの小さな単純なプログラムでは、ブリッジがどちらの側でも使用できる機能を「想定」するのが一般的です。ただし、プログラムがより複雑になると、非効率性やバグの多い想定を回避できるように、ビューとモデルがその機能をブリッジに報告することをお勧めします。
ほぼカバーしていると思います。どうしても、私がよく使用するデザインについての質問があれば歓迎します。同様に、どんな提案も勧めます。
そしていつものように、あなたの時間をありがとう。
あなたのフレーズ
「モデルとビューの間のコーディネーターとトランスレーターです。」
ブリッジがMVPアーキテクチャのプレゼンターであることを示します。
MVPとMVCは非常に似ていますが、MVPではプレゼンターのみがモデルを監視しますが、MVCではビューはモデルを直接監視することもできます（プレゼンターを「ブリッジ」として使用する必要はありません）。
モデルの責任
「データが変更されたときにBridgeに通知します（Bridgeが関心を示したデータの場合）」。
おそらく不適切な言い回しまたは間違いです。モデルにBridge/Presenter/ControllerまたはViewのいずれにも依存させたくない場合。代わりに、オブザーバーパターン、イベント、またはリアクティブプログラミングのいずれかを使用して、ブリッジがモデルの変更にsubscribeできるようにします。そして、あなたはあなたの責任を次のように言い換えることができます：
「外部のサブスクライバー（何も知らない）が状態または計算結果を監視できるようにします。」
モデルがコントローラーまたはビューに依存しない場合、テストが容易になり、移植性が大幅に向上します。
あなたを混乱させることの1つは、両方とも一般にmodel-view-controllerと呼ばれている2つの完全に異なるパターンがあることです。
Smalltalkで実装され、ローカルguiシステムに役立つオリジナルがあります。また、コントローラーがサーバー上に配置できるようにビューとコントローラーの責任の一部を交換する、私がweb-mvcと考える傾向があるものもあります。クライアント上にあるビュー（おそらくレンダリングされたhtmlとして、または多分ajaxを介して）。
あなたの説明は、web-mvcのほとんどの定義に収まるように聞こえます。
この正確な命名法については、プログラミングコミュニティで多くの議論があります。誰もがほとんど何についても同意しないようです。
私にとって、ブリッジがビューにどのように接続されているかによって、名前が決まります。
- ブリッジごとにビューのコレクションが存在する場合、そのブリッジはコントローラーです。
- ブリッジごとに常に1つのビューがある場合、ブリッジはプレゼンターです。
- ビューごとにブリッジのコレクションがある場合、そのブリッジはビューモデルです。
時には物事はそれほど明確ではありません。たとえば、プレゼンターを複数のサブビューで構成される複合ビューに接続したり、ビューの知識がなくてもコントローラーを作成したりできます。それにもかかわらず、私のルールは良い出発点だと思います。
余談ですが、私は次のように責任を組み合わせたいと思います。
型番
主な責任：永続的なデータ
第2の役割：更新を検証し、オブザーバーに更新を通知します
見る
主な責任：現在のデータ
第2の役割：入力を受け入れる、UXを提示する
ブリッジ
主な責任：データの更新
第2の役割：クリーンな入力、データとビューの同期
提案されたパターンは表面上は正しいように見え、小さなインスタンスでは間違いなく機能しますが、アプリがより複雑になると、何が何を更新し、誰がどこでリッスンするのか、なぜ私が試みているのかわからないという問題に直面します非常に多くのビュー内から非常に多くのモデルを制御するために、すべてが互いにアクセスする必要がある人など.
次のパターンを使用してアイデアを拡張することをお勧めします（Amy Palamountainの講演から引用 Enemy of the State ）：
モデル
- 状態をデータストアと同期する
- 新規/更新されたデータの検証を処理する
- 状態が変化したときにイベントを発生させる
ビュー
- テンプレートをレンダリングする
- モデルイベントの処理
- DOMイベントを処理する
- モデルとDOM間の相互作用を仲介します
コントローラ
- 多くてもカップルモデルとビューの管理
- コンテナ内のビューを追跡します
モジュール
- コントローラーとそのビューおよびモデルの論理グループ
- テスト可能
- 小規模で保守可能（単一の責任）
- コントローラーに含まれるビューとモデルの状態とイベントを（コントローラーを介して）調整します
- 独自のビューを自由に提示
- Not自由に選択whereそのビューを提示する
レイアウトマネージャー
- レイアウト構成を担当
- モジュールがコンテンツを提示できる領域を持つDOMのアプリケーションシェルを定義します
ディスパッチャ
- イベントをリッスンします（グローバルPubSubストリームを介して）
- イベントに基づいて新しいモジュールをロードする責任があります
- ロードされたモジュールをレイアウトマネージャーに引き渡す
- モジュールの全ライフタイムを管理します（作成、クリーンアップ、キャッシュなど）
- イベントの例：
- ルート変更（初期ロードルートを含む）
- ユーザーインタラクション
- サーバー側の状態変更などにより、モデルイベントからバブルされたモジュールイベント
アプリケーション
- 全体的なセットアップを担当し、次のようなものをインスタンス化します。
- 発車係
- ルーター
- PubSubストリーム
- ロガー
- 等
この種のパターンを使用すると、アプリケーションを構成可能にし、単体テストを行ったり、Bridgeが時間の経過とともに構築する複雑性を取り除いたり、懸念を適切に分離したりできます。
エイミーが指摘するように：クライアント上にサーバーを構築しないように注意してください。そしてdoctrine）に陥らないように注意してください。代わりに、これらすべてのアイデア（およびここでの他の答え）を取り、アプリケーションとチームに最適なもの。
Amy Palamountainの講演をご覧になることを強くお勧めします Enemy of the State （そこからこれらのアイデアが生まれました）、または少なくとも見直す 講演のスライド =。