<< 클라우드 환경에서 새로운 ACID, BASE 그리고 CAP | Home | FriendFeed에서는 어떻게 MySQL에 Schema-Less 데이터를 저장하는가? >>

MVC의 시대는 가고 MOVE의 시대가 온다.

MVC is dead, it's time to MOVE on.

이 글은 Conrad Irwin의 MVC is dead, it's time to MOVE on.이라는 아티클을 번역한 글임을 알립니다. 영어실력이 워낙 미천해서 내용중에 저자의 의도와 사뭇 다르게 튈 수도 있으니, 이 점 너그러이 용서를 바라오며 틀린 부분이 있으면 댓글로 주시면 반영하도록 하겠습니다.
본론에 들어가면..


MVC는 멋진 아이디어다. 독립적인 상태의 집합을 가진 Model, UI 정보를 가진 View, 그리고 Controller...
사람들은 각 영역(MVC)을 분리하는게 힘들어서 컨트롤러에 불필요하게 많은 코드들을 양산하게 된다는 것이 MVC가 가지고 있는 문제점이라도 한다.
그래서 이 문제를 해소하기 위해서 MOVE(Models, Operations, Views, Events) 패턴을 사용해야 한다고 필자는 주장하고 있다.

MOVE란?

아래의 그림은 MOVE 애플리케이션 구조를 보여주고 있다.



  • Model은 애플리케이션들이 알고 있는 모든 것(knowledge)들을 캡슐화한다.
  • Operation은 애플리케이션이 수행하는 모든 것을 캡슐화한다.
  • View는 애플리케이션과 사용자 사이를 중재한다.
  • Event는 모든 콤포넌트(구성 요소)들을 안전하게 연결하는데 사용된다.
스파케티 코드를 양산하지 않기 위해서 중요한 것은 각 유형의 객체들이 무엇을 해도 좋은가를 제안하는 것이다. 이것을 위해 위의 그림에서 화살표를 사용한다. 예로 View는 Model로부터 Event를 받고 Operation은 Model의 변경할 수 있지만, Model은 View나 Operation을 참조하지 못한다.

Models

전형적인 모델로 "사용자" 객체가 있다. 적어도 메일 주소와 이름, 전화번호를 갖고 있다.
MOVE 애플리케이션에서 Model은 지식을 래핑하는 것이다. 거기에 getters, setters 그리고 사용자의 패스워드를 체크하는 함수를 포함할 수도 있다. 그러나 데이터 베이스에 사용자 정보를 저장하거나 외부 API에 업로드하는 함수는 포함되지 않는다. 이런 것들은 Operation이 할 일이다.

Operations

애플리케이션에서 공통적인 Operation이라고 하면, 사용자의 로그인이 있다. 이것은 두 단계의 하위 작업을 조합한 것이다. 첫 번째는 사용자 이메일과 비밀 번호를 얻는 것이고 두 번째는 "사용자"모델을 데이터베이스에서 읽고 암호가 올바른지 확인하는 것이다.
Operation은 MOVE 세계에서 다재다능하다. 모델을 변경하고 적절한 때 적절한 View를 표시하고 사용자와 상호 작용에 의해 발생되는 이벤트 응답하는 역할을 한다. 각 요소(역할)들이 잘 분리된 애플리케이션에서는 하위 오퍼레이션들은 부모로부터 독립적으로 실행될 수 있다.
이것은 위의 그림에서 이벤트의 방향이 위쪽으로는 부모로 향해 있고, 변경은 아래로 자식을 향해 있는 이유이다.
이 방법으로 Operation을 사용함으로써 재미있는 것은 전체 애플리케이션이 해당 프로그램의 부팅 시간에 시작하는 오퍼레이션으로써 처리될 수 있다는 것이다. 현재 존재하는 각 하위 오퍼레이션은 병렬적으로 실행되고 필요한 만큼 하위 오퍼레이션을 생성하고 모두 완료하면 프로그램이 종료된다.

Views

로그인 화면은 일부 텍스트 박스를 사용자에게 보여주는 역할을 하는 하나의 View이다. 사용자가 "로그인"버튼을 클릭하면 View는 사용자가 입력한 사용자 이름과 암호를 포함한 "loginAttempt" 이벤트가 발생한다.
사용자가 보고, 조작 하는 모든 것은 View에 의해 제어된다. 그들은 애플리케이션 상태를 알기 쉽게 표시할 뿐만 아니라 유입되는 사용자 상호작용 흐름을 의미있는 이벤트로 단순화시킨다. 중요한 것은, View는 Model을 직접 변경하지 못하고 단순히 Operation으로 이벤트를 보낸다. 그리고 Model에서 발생되는 이벤트를 모니터링하면서 변화를 기다린다.

Events

"loginAttempt" 이벤트는 사용자가 "로그인"버튼을 누를 때 View에서 보내진다. 또한 로그인 작업이 완료된 때 "currentUser" Model은 자신이 변경된 것을 애플리케이션에 전달하는 이벤트를 발생시킨다.
이벤트에 대한 모니터링은 어떤 뷰가 업데이트되는 것을 모델이 직접 신경쓰지 않아도 되도록 모델이 뷰를 업데이트시킬 필요가 있다는 것을 MOVE에게 IoC를 줄 것이다. 이것은 구성 요소끼리 서로 간섭하지 않고 연결할 수 있도록 하기 위한 매우 강력한 추상화 기술이다.

왜 지금 MOVE를 사용해야 하는지?

오해하지 않았으면 좋겠고, MVC가 나쁘다는 것은 아니다. 수 십년 동안 MVC는 큰 애플리케이션을 구성하기 위한 매우 훌륭한 방법이었다.
하지만, MVC가 나오고나서 새로운 프로그래밍 기술이 일부 퍼졌다. closures가 없었다면 이벤트 바인딩은 매우 힘들었으며, deferrables이 없었다면 개별 오퍼레이션을 객체로 직접 다룬다는 생각은 전혀 의미가 없다.
MVC는 훌륭하지만 수십년 전에 디자인된 기술이다. 하지만, MOVE는 우리가 새로운 도구를 보다 효율적으로 사용하게 하기 위해 업데이트 되고 있다.

참고로 MOVE 아이디어를 좋아하는 경우에, objectifyinteractions을 확인해 본다면 좋을 것이다. 이곳은 기존 MVC 바탕에 MOVE의 장점을 시도하고 있는 곳이다.

[참조 사이트]
Tags : , ,


Avatar: Anonymous

Re: MVC의 시대는 가고 MOVE의 시대가 온다.

 참조 할 수 있도록 링크해주신 곳을 참조하려다 보니 404가 뜨네요...

 

move 패턴을 사용한 셈플이 있다면 공유 부탁드립니다.

 

 

 


Add a comment Send a TrackBack