네트워크 이론 및 MVC

Question

뷰 (양식) 간의 커뮤니케이션을 허용하지 않는 MVC를 설계했습니다. 양식이 다른 양식과 통신 해야하는 경우 컨트롤러에서 이벤트가 생겨 다른 양식이 구독 할 수 있습니다. 일반적인 아이디어는 의사 소통 경로를 최소한으로 유지하여 복잡성을 유지하는 것입니다. 각보기는 싱글 톤 또는 서브 컨트롤러 인 rootcontroller와 통신하며, view는 rootcontroller를 통해 액세스합니다. 다시 말하지만, 모든 것이 루트 컨트롤러를 통과하기 때문에 통신 경로를 유지합니다.

이것은 네트워크에 더 많은 노드를 추가할수록 더 복잡한 일반적인 네트워크 이론을 따릅니다. "및", 이러한 노드 각각이 직접 통신할수록 네트워크에 더 복잡해집니다. 누구 든지이 영역/이론이 정확히 무엇을 지적 할 수 있습니까? 참조?

MVC로하고있는 일이 네트워크의 모든 노드가 서로 통신하기 위해 중앙 노드를 통과하는 것과 유사합니까?

Answer 1

그래프 이론 (네트워크 토폴로지의 기초)을 찾아보고 싶을 수도 있습니다.

그리고 솔루션은 네트워크의 중앙 노드를 통해 모든 것이 통신하는 것과 유사한 것처럼 들립니다. 이것은 단순성을위한 좋은 패턴입니다 (각각의 새 노드는 모든 것에 연결하기 위해 하나의 연결이 필요합니다). 루트 컨트롤러가 수행하는 작업의 양이 크기 때문에 확장성에 불과합니다. 각각의 새로운 노드는 중앙 노드에 주요 성능 병목 현상을 더 가까이 제공합니다.

Answer 2

실제로 그것은 것 같습니다 중재인 패턴 ... 모든 커뮤니케이션은 중앙 허브를 통해 발생합니다 ...

Answer 3

기본처럼 들립니다 관찰자 패턴.

Answer 4

Well, if you have a complete graph (where a given node is directly connected to every other node), then it would be n(n-1)/2 edges and O(n^2)... Is that what you're looking for?

For hub-and-spoke, you're looking at n-1 edges and O(n) complexity.

However, in the many rails apps that I have worked on, allowing views to call other views has never (that I can recall) caused many problems... it would actually be really difficult to work the whole 'partial' thing without it.

Answer 5

네트워크/그래프 이론이 여기서 정말 도움이 될지 확신 할 수 없습니다. 모든 "경로"는 길이 1입니다. 길이는 1입니다. 더 많은 형태가 많을수록 이러한 형태가 더 많이 상호 작용할수록 응용 프로그램이 더 복잡하다는 것은 자명 해 보입니다. 응용 프로그램을 모델링하려는 경우 보는 것이 더 좋을 것 같습니다. 메시지 전달, 그래프 이론보다는.