지금은 되게 당연하게 받아들이게 된 이론인 MVC, MVVM 같은 녀석들을 왜 이용하는지에 대해서는 솔직히 이런 걸 먼저 가르치면서 해야 한다고 생각은 하는데… 사실 이런 내용은 현업에서 하다보면 나중에 되어서야 알게 되는 참 힘든 내용인 듯 하다.
개발 초기 단계에서 회의 끝에 초기의 UI 모양이나 조작에 대한 사양은 정해진 거 같으면서도 정해져 있지 않다고 보면 된다. (즉, 나중에 미친 듯 갈릴 수 있다는 것이다.) 그래서 리치 클라이언트 응용 프로그램의 경우에는 어플리케이션 설계 시에 계층 구조를 가지고 개발을 하는 것이 좋다. 전통적으로 보는 계층 구조는 다음과 같은 것들이 있다.
- 자산: 주로 이미지 소재 같은 가공된 내용물들임.
- 상호작용: 이벤트 등에 대한 시스템이 반응하는 녀석
- 컨트롤, 레이아웃: 그래픽 컨트롤들과 그를 배치한 레이아웃
- 이벤트: 사용자 인터페이스에 대한 조작 관련 이벤트들
- 비즈니스 로직: 응용 프로그램이 처리할 처리 내용이나 그에 대한 기준 데이터들
이런 것들을 우리는 어디서 비슷한 녀석을 본 거 같다. 바로 이 글의 맨 앞에서 이야기 한 응용 프로그램 개발할 때 프로그램 구조에서 이야기하는 디자인 패턴들, MVC, MVVM 같은 녀석들 설명 듣고 할 때 많이 본 것들이다. 리치 클라이언트에서는 뷰에 대한 요구와 수정이 주로 일어나기 때문에 뷰에 대한 것과 뷰를 구성하고 실행하는 것에 대해서 분리하여 처리하는 여러 과정들 중 일부들… 바로 이런 것들 땜에 나오는 이야기인 거다.
여기서는 좀 전통적인 로직에 맞춰서 설명을 하겠다. (규링은 이런 내용에 기반한 걸 먼저 배운 관계로…ㅠㅠ) 최하층의 비즈니스 로직과 이벤트는 사실 개발 도중에 변경 사항이 나오기 상당히 드문 것들이다. 이게 바뀐다는 건 사용하는 데 있어서 필요한 비즈니스 로직 자체가 바뀌었다는 내용이 되기 때문이다. 그리고 이것들은 중간에 있는 컨트롤, 레이아웃에 의해 호출되어 결과만 제대로 나와주면 되기 때문에 컨트롤과 레이아웃에 대해서는 어느 정도의 사양만 제대로 갖춰지기만 해도 충분히 맞춰 개발할 수 있다.
문제는 상위에 있는 자산, 상호작용 부분들인데, 이 부분들에 대해서는 할 말이 없다….;ㅅ; 사실 끝의 끝까지 가서도 바뀔 수 있는 녀석들이다. 그래서 이 영역의 코드들은 마지막의 마지막까지 그냥 “튜닝한다” 라는 내겸을 가지고 가야 한다. 그래서 코드 분리의 개념이 엄청나게 잘 되어있고 그걸 당연한 듯이 설명하고 그걸 잘 이용하기 위한 프레임워크들을 이용하는 것이지만….ㅇㅂㅇ;;;;