ASP.NET MVC 프레임웍의 정식 출시를 앞두고 이의 구현과 연관된, 혹은 이와 연동하는 프레임웍에 대한 논의가 활성화되고 있다. 또한 단순 프레임웍 차원이 아니라 관련 패턴 설명서, 참조 구현, 아키텍처 관련 설명, 툴 지원 등등을 묶어 마이크로소프트 P&P (Pattners and Practices) 팀에서 Software Factory라는 이름으로 시리즈를 내고 있다. 하여 ASP.NET MVC와 연동 혹은 경쟁하게 될 Software Factory로는 Web Client Software Factory (WCSF, http://www.codeplex.com/websf)가 있으며, 이미 블로그 스피어 상에는 둘 사이의 차이점 및 연동 방안 등에 대한 글들이 올라오고 있다. 기존 ASP.NET이 MVC 패턴 중 Page Controller를 구현한 것과는 달리, ASP.NET MVC는 이름에서 말하고 있듯이 MVC 패턴 중에서 Front Controller 패턴을 구현하고 있다. 아울러 WCSF는 잘 알려진 바 대로 Application Controller 패턴을 구현하고 있다.
Page Controller나 Front Controller에 대해서는 P&P 책자에서도 상세히 설명되고 있고, 이를 기반으로 한 2년 전에 필자가 웹 캐스트를 찍은 것이 마이크로소프트 홈페이지 e-learning 싸이트에 여전히 올라가 있으니 관심있는 사람들은 이를 참고하면 좋을 듯 하다. 이 시간에는 Application Controller에 대해 살펴보기로 하고 이를 통해 다음 기회에 작성할 WCSF에 대한 이해를 높이는 기회가 되었으면 한다.
Application Controller가 웹 애플리케이션의 프리젠테이션 티어에서 주로 사용하는 것이나 특성상 꼭 그런 것은 아니다. 여기서는 웹 프리젠테이션 티어에서 사용되는 것을 통해 Application Controller가 여타 다른 Controller 패턴 들과 연동하는 모습을 살펴보기로 한다. 일반적으로 웹 프리젠테이션 티어는 Page Controller나 Front Controller 패턴을 구현한 프레임웍을 통해 구성되며, 대부분의 경우 이러한 Controller만으로 족하다. 하지만 UI 로직이 복잡해져서 사용자에게 전달될 화면이 특정 순서로 제공되어야 하거나, 혹은 사용자 세션의 현재 상태 혹은 시스템의 현재 상태에 따라서, 즉 상태 머신 (State Machine)처럼, 상태 기반으로 제공되는 화면이 달라야 하는 경우에는 Page Controller나 Front Controller를 통해 구현하기에는 벅차다. 즉, Page Controller 기반이라면 여러 Controller들에게 똑같은 혹은 비슷한 로직이 중복될 것이며, Front Controller로 구현한다면 Controller 자체가 너무 비대해져서 시스템의 규모가 커지거나 향후 유지보수 시에 융통성이 떨어지게 된다. 또한 이러한 Controller 들은 웹 프로토콜에 직접 노출되기 때문에 테스트에 취약하다.
Application Controller는 이러한 Controller 뒤에 위치하여 사용자의 요구에 부합되는 비지니스 로직 모듈을 찾아 수행하고 결과에 맞는 화면을 제공하는 역할을 한다. 즉, 일반적으로 Front Controller가 담당하는 역할 중에서 웹 인터페이스 부분은 여전히 Front Controller에 맡기고, 웹과 한 발 떨어져 일반 클래스로 위에서 언급한 애플리케이션 흐름을 제어하는 역할을 한다. 따라서 간단한 웹 애플리케이션의 경우 Application Controller 없이 Front Controller만으로 족하나, 시스템의 복잡성, 특히 화면 관련 흐름 제어 로직이 복잡해질 경우 이를 별도의 모듈, 즉, Application Controller로 떼어내는 것이 바람직하다. 이렇게 되면 Application Controller 자체는 웹 특성을 많은 부분 없앨 수 있어 단위 테스트 등의 테스팅 프레임웍을 이용하는 것이 한결 쉬워진다.
일부 문서에서는 Application Controller를 별도 패턴으로 인정하지 않고 Front Controller의 Helper로 기술하는 경우도 있다. 닷넷의 경우 WCSF가 Application Controller를 구현한 것으로 여겨지고, 자바의 경우 Struts가 대표적이다. Struts의 경우 초반에는 ActionServlet이라는 Front Controller 만으로 구현되어 있었는데, 버전이 올라가면서 ActionServlet이외에 RequestProcessor를 두어 웹과 인터페이스하는 부분을 제외한 모든 일, 즉, Filter Chain 적용하기, 맵핑 정보 확인, 사용자 요구에 맞는 비지니스 모듈 찾기 (주로 Command 패턴으로 구현), 비지니스 로직 수행 결과에 따른 뷰 찾기 등등을 모두 RequestProcessor에 일임한다. ActionServlet은 Front Controller이고 RequestProcessor는 Application Controller이다.
위 그림에서 Command Factory나 View Factory 등은 모두 생략하였으며, 궁극적으로 Application Controller가 애플리케이션 흐름 제어에 필요한 클래스를 찾아 수행하고 결과를 반환하는 역할을 함을 보여준다. 이름이 의미하듯 Application Controller이며, 이 Controller에 비지니스 도메인과 관련된 로직을 담는 것은 바람직하다고 여져진다. 즉, 도메인과 상관없이 애플리케이션 차원에서 필요한 로직들, 화면 전환이나 이를 위해 필요한 각종 판단 근거가 되는 정보 들, Mapper 등등이 여기에 관여된다. 애플리케이션 로직과 도메인 관련 비지니스 로직의 구분이 모호할 경우, 마틴 파울러는 한번으로 끝나는 것은 Applicatin Controller 로직에 포함하고 여러 곳에서 자주 쓰이는 로직은 비지니스 모듈쪽으로 빼는 것이 바람직하다는 의견을 제시한다. Application Controller에 대해서는 이미 마틴 파울러의 웹 싸이트 및 그의 저서 Patterns of Enterprise Application Architecture (P of EAA) 에서 상세히 설명하고 있다. P of EAA에서는 약간 추상적인 논의가 많아서 재미없어 하는 분이 있다면, 자바 관련 서적이긴 하지만, Core J2EE Patterns를 참고해도 좋다.
