MVC ?
- Model + View + Controller 를 합친 용어로 이상적은 구현은 각 구조는 서로의 존재를 몰라야하며 단순해야한다.
- 즉 각각 역할을 나누어 코드 관리를 하여 직관성과 유지보수 성의 향상을 꾀한다.
- 낮은 결합도와 높은 응집력을 위해 나누어졌다.
1. 흐름
생각하던 Mvc 와 Facebook 이 보여준 MVC
- Flux 패턴을 읽으면서 가장 의아 했던것은 왜 View 와 Model 서로 통신하지? 였다.
- 계정, 멘트, 아이콘, 이벤트 등의 다양한 Model 을 사용하는 Facebook 에서 다양한 Model 과 각각의 View 가 있을 것 같다.
- 하나의 Model 변화는 다른 View 로 전파되고 View 의 변경은 다른 Model 로 전파되는 것을 보면 결합도가 점점 올라가는 것으로 보인다.
- 하지만, MVC 패턴에서 왜 Controller 를 통하지 않고 View 와 Model이 통신하고 있는가? 는 의문이다.
- Action 은 Controller가 받아 Model 을 갱신하고 Controller 가 선택한 View 에 Model 을 담는 게 내가 아는 MVC 동작구조이다.
- 즉 Action 과 View 는 Controller 에서 받아지고 선택되어 지는 것이 아니였나..하는 위화감이 든다.
- 물론 과도한 요청을 Controller 가 받아내어 응답을 보내는 것과 View 단에서 바로 Model 을 조작시키는 것은 커다란 성능차이를 보여줄 것같다.
- MVC 에서 Controller 와 View 는 1 : N 의 관계이다.
- View 는 Controller 를 몰라야하기 때문에 선택만 되어지고 갱신되지는 못한다.
- MVC 패턴의 단점인 Model과 View 의 결합도 상승도 이슈였을 지 모른다.
- Controller 가 점점 더 비대해진다는 것도 주요 이슈 사항일 것 같다.
- Facebook 의 MVC 에서 View 단에서 이벤트리스너에서 데이터 처리가 들어갔다고 가정하면 이벤트와 데이터 추적은 정말정말 어려울 것 같다.
- 그래서 SingeTon 의 Store 를 두어 이벤트를 하나에서 관리하고 Monitoring 하게 된 것 은 아닐까 싶다.
-
- 중앙에 컨트롤러를 두고 추적에 들어가면 보다 추적이 용이해지지 않았을까 하는 생각도 조심스레 해본다.
