3

ビュー（フォーム）間の通信を許可しないMVCを設計しました。フォームが別のフォームと通信する必要がある場合、他のフォームがサブスクライブできるコントローラーでイベントを発生させます。一般的な考え方は、通信のパスを最小限に抑え、複雑さを抑えるのに役立つことです。各ビューは、シングルトンであるRootController、またはビューがRootControllerを介してアクセスするsubControllerと通信します。繰り返しになりますが、すべてがRootControllerを通過するため、通信パスはダウンしたままになります。

これは、ネットワークに追加するノードが多いほど、ネットワークが複雑になるという一般的なネットワーク理論に従っていますか。「そして」、これらのノードのそれぞれが直接通信するほど、ネットワークに複雑さが増します。誰かがこの領域/理論が正確に何と呼ばれているのかを指摘できますか？参照？

私がMVCで行っていることは、ネットワーク上のすべてのノードが中央ノードを経由して相互に通信することに似ていますか？

4

5 に答える 5

4

グラフ理論 (ネットワーク トポロジーの基礎) を調べるとよいと思います。

そして、あなたのソリューションは、ネットワーク内の中央ノードを介してすべてが通信することに類似しているように聞こえます。これは単純化には適したパターンですが (新しいノードごとにすべてに接続するために必要な接続は 1 つだけです)、RootController が実行する作業量が膨大になる点に到達するため、スケーラビリティーには不利です。新しいノードごとに、セントラル ノードで主要なパフォーマンスのボトルネックが発生する可能性が高くなります。

于 2009-01-19T15:39:41.297 に答える
3

実際にはメディエーターパターンのように聞こえます...すべての通信は中央ハブを介して行われます...

于 2009-01-19T15:38:19.927 に答える
1

完全なグラフ（特定のノードが他のすべてのノードに直接接続されている場合）がある場合、それはn（n-1）/ 2のエッジとO（n ^ 2）になります...それがあなたのことです再探していますか？

ハブアンドスポークの場合、n-1個のエッジとO（n）の複雑さを確認しています。

しかし、私が取り組んできた多くのRailsアプリでは、ビューが他のビューを呼び出せるようにすることで、多くの問題が発生することはありませんでした。

于 2009-01-19T16:45:00.120 に答える
1

基本的なオブザーバー パターンのように聞こえます。

于 2009-01-19T15:35:00.387 に答える
0

ここでネットワーク/グラフ理論が本当に役立つかどうかはわかりません。すべての「パス」の長さは 1 です。フォームの数が多いほど、またこれらのフォームが互いに相互作用するほど、アプリケーションが複雑になることは自明のことです。アプリケーションのモデル化を検討している場合は、グラフ理論よりもメッセージ パッシングを検討する方がよいと思います。

于 2009-01-19T15:43:40.993 に答える