ASP.NET2009.04.08 19:09

ASP.NET MVC 의 하나의 요청에 대한 Life Cycle을 표현하면 아래와 같다.


기존 웹폼의 Page Controller에 비해서 ASP.NET MVC의 Front Controller 패턴은 요청 하나에 대해서 많은 일들을 한다.
Front Controller 패턴의 경우 요청을 중앙 집중식으로 하여 각각의 로직을 분산 시키는데 효과적이다. 이를 Facade Pattern 이라고도 하는데 Spring Framework 을 사용하기에 용이 하다.


다시말해서 Facade Pattern 으로 설계가 되면 DI(Dependency Injection)가 용이해 지기 때문이다.

위 ASP.NET MVC Life Cycle 에서 클라이언트의 ①요청에 대한 진입점을 Global.asax 에서 미리 정의한 라우팅 맵을 통해 요청이 해당 Controller로 처리된다. Controller는 클라이언트가 요청한 작업을 처리 하기 위해 Model 에서 데이터를 가공하여 다시 Controller로 가져온다.(이 부분은 메서드 호출이라고 생각하면 됨)
원하는 데이터를 가져와서(특정 요청을 처리한 후) System.Web.Mvc.ViewDataDictionary 에 실어서 View로 데이터를 전달한다.

자... 여기서 일반적인 ASP.NET MVC 에 대한 하나의 Life Cycle을 살펴봤는데, 실제 프로젝트를 생성 해 보면, 약간 아쉬운점이 보인다. 가장 처음 들르는곳 Global.asax의 RegisterRouters 메서드 이다.


코드를 보면 라우팅 규칙이 하드코딩 되어있다. 약간 안습(?)이다. 물론 Creativity를 겸비한 개발자는 이 부분을 XML로 config 설정을 할텐데... MVC 모델로 개발하는 이유가 유지보수에 용이한 모델이고 확장이 쉽고 등등.. 하지만 하드코딩되어 있다면 과감하게 외부로 빼는게 좋을듯 하다. 라우팅을 외부로 빼게 되면, 그 정의를 Spring에서 할 수 있고, 진입전에 DI를 쉽게 할 수 있다.

이처럼 라우팅 테이블의 단점을 스프링이 보완해 준다. 또하나...
만약에 어떠한 비즈니스 로직이 있다는 가정하에서 그 비즈니스 로직이 실행되기전 다른 작업, 또는 실행 후 다른작업이 추가가 되어야 할때 SPRING.NET 이 가지고 있는 AOP(Aspect Oriented Programming)의 Advice, Pointcut, Advisor를 통해 가능하다. 이게 바로 또하나의 선물이다.

MVC모델에 대해서 부족한 부분을 채워 주는것이 AOP이며 꼭 ASP.NET MVC 모델로 개발을 해야 할때는 SPRING.NET의 탑재를 심각하게 고민해 보아야 할 부분이다.
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by dotnetpower

티스토리 툴바