Spring
Spring MVC 에 대해 알아보자
고물라됴
2011. 9. 12. 01:36
바쁘다는 핑계로 포스팅을 오랜만에 한다.
난 바쁜게 맞는데 왜 결과물은 눈에 보이지 않는거지...?
1일 1 포스팅은 꼭 하고 싶은데,
이게 보는 것처럼 쉬운게 아니구나....
오늘 포스팅 할 내용은 Spring MVC 에 관한 내용.
즉
Spring MVC는 요거만 알면 된다!!!................는 아니고
Spring MVC를 하는데 요걸 모르면 절대 안된다..........정도가 되겠다.
일단 Spring MVC 에 들어가기에 앞서 Model1 방식 과 Model2 방식의 차이점에 대해 알아보겠다.
요것이 Model1 방식
난 바쁜게 맞는데 왜 결과물은 눈에 보이지 않는거지...?
1일 1 포스팅은 꼭 하고 싶은데,
이게 보는 것처럼 쉬운게 아니구나....
오늘 포스팅 할 내용은 Spring MVC 에 관한 내용.
즉
Spring MVC는 요거만 알면 된다!!!................는 아니고
Spring MVC를 하는데 요걸 모르면 절대 안된다..........정도가 되겠다.
일단 Spring MVC 에 들어가기에 앞서 Model1 방식 과 Model2 방식의 차이점에 대해 알아보겠다.
요것이 Model1 방식
그림에서 보는 것과 같이
Model 1 방식은 request 의 요청에 대한 처리와 유효성 검증, 비지니스 로직 핸들링, response 의 생성 등
모든 책임을 JSP 단독으로 지게 된다. ㄷㄷㄷㄷㄷ
일단 간단하다.
하나의 페이지에 client programing 과 server programing, Model 과 View, Tag 와 Java code를 몰아 넣으면 된다. 이게 어떻게 보면 개발속도가 빠를수도 있겠다.
또한 개발자의 스킬이 낮아도 배우기 쉽고 빠르게 개발을 시작 할 수 있을 것이다.
그러나 당연히 단점도 있는법. 단점도 보통 단점이 아닌...
JSP 가 혼자서 모든 처리를 하기 때문에 역할 분담이 되지 않고 페이지가 복잡해지는건 당연지사다.
또 개발자와 디자이너의 분리된 작업이 어려워지게 된다. (웹디자이너가 욕도 아주 쌍욕을 할수도 있을듯)
또한 페이지가 복잡하다 보니 구현된 기능들의 연관 관계를 파악하는 가독성이 떨어질 것이고
변경 할 것이 생겼을때 그것을 변경해 버리면 영향을 미치는 범위가 커지는 위험이 따를 수 있을 것이다.
즉 유지보수가 어렵다는 뜻이 되겠다.
그럼 Model 2의 방식을 살펴보자.
요것이 Model2 방식
Model 1 방식은 request 의 요청에 대한 처리와 유효성 검증, 비지니스 로직 핸들링, response 의 생성 등
모든 책임을 JSP 단독으로 지게 된다. ㄷㄷㄷㄷㄷ
과거의 단순한 Web Application들은 Model 1방식으로도 충분했을 것이라고 짐작된다.
이 Model 1방식은 나름의 장점을 가지고 있는데 그것은 쉽게 유추해 낼수 있다.일단 간단하다.
하나의 페이지에 client programing 과 server programing, Model 과 View, Tag 와 Java code를 몰아 넣으면 된다. 이게 어떻게 보면 개발속도가 빠를수도 있겠다.
또한 개발자의 스킬이 낮아도 배우기 쉽고 빠르게 개발을 시작 할 수 있을 것이다.
그러나 당연히 단점도 있는법. 단점도 보통 단점이 아닌...
JSP 가 혼자서 모든 처리를 하기 때문에 역할 분담이 되지 않고 페이지가 복잡해지는건 당연지사다.
또 개발자와 디자이너의 분리된 작업이 어려워지게 된다. (웹디자이너가 욕도 아주 쌍욕을 할수도 있을듯)
또한 페이지가 복잡하다 보니 구현된 기능들의 연관 관계를 파악하는 가독성이 떨어질 것이고
변경 할 것이 생겼을때 그것을 변경해 버리면 영향을 미치는 범위가 커지는 위험이 따를 수 있을 것이다.
즉 유지보수가 어렵다는 뜻이 되겠다.
그럼 Model 2의 방식을 살펴보자.
요것이 Model2 방식
그림에서 보는 것과 같이 MVC 디자인 패턴을 이용하여 JSP가 하는 일을 좀 덜어주었다.
MVC는 Model-View-Controller로 각각의 역할을 나누어 작업하고자 하는 일을 분담시키는 것을 말한다.
Model은 Application 로직을 담당하는 부분으로 Database나 Legacy System과의 로직을 담당하는 부분을 말한다. Model은 View나 Controller 로 부터 독립되어있다.
View는 사용자가 직접 사용하는 부분으로 Presentation 로직을 담당하는 부분이다. Controller와 Model에 의해 생성된 결과물을 보여주는 역할을 한다.
Controller는 Business Logic을 담당하는 부분으로 사용자의 요청을 받아 요청에 해당하는 작업을 한 후 작업 결과에 따라 응답을 결정하는 역할을 한다. Model과 View사이에서 데이터를 전달하는 역할을 한다.
즉 Model 2는 이 같은 MVC구조를 웹에 적용하여 개발하는 방식이다. View는 JSP가 담당하고, Controller는 Servlet, Model은 application을 이용하여 개발하는 방식을 말한다.
Model 2의 장점은 무궁무진하다.
이 Model 2는 중급 이상 규모의 어플리케이션을 개발할 때 Model 1 구조로는 해결하기 어려운 부분을 대응이 가능하다고 한다.
그리고 유지보수에 유리할수 밖에 없다. 예를 들어 열심히 짜놓은 view 부분을 고객이 갑자기 플래쉬로 짜달라고 한다. JSP 가 모든 것을 책임 지는 Model 1 방식 같으면 고객의 멱살을 잡고 그냥....은 절대 농담이고, 피똥싸며 야근하겠지만 Model 2 방식은 view 부분을 담당하는 쪽만 플래쉬로 바꿔주면 그만이다.
하지만 이렇게 좋은 Model 2도 단점이 존재하는데...
일단 Model 1 의 개발 방식보다 어렵다고들 한다. 그리고 시간도 많이 걸린다고 한다.
하지만 이 단점을 충분히 커버할 만한 유지보수 의 위대함 앞에서
Model 2 는 너무나 당연한 선택이겠지...
그럼 이제 본격적으로(응?????) Spring MVC 에 대해 포스팅 하고자 한다.
Spring MVC는 Spring 에서 제공하는 MVC 기반의 웹 프레임워크이다.
Anyframe 의 메뉴얼에는 Spring MVC 의 특징을 아래와 같이 소개한다.
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------
즉 Model 2는 이 같은 MVC구조를 웹에 적용하여 개발하는 방식이다. View는 JSP가 담당하고, Controller는 Servlet, Model은 application을 이용하여 개발하는 방식을 말한다.
Model 2의 장점은 무궁무진하다.
이 Model 2는 중급 이상 규모의 어플리케이션을 개발할 때 Model 1 구조로는 해결하기 어려운 부분을 대응이 가능하다고 한다.
그리고 유지보수에 유리할수 밖에 없다. 예를 들어 열심히 짜놓은 view 부분을 고객이 갑자기 플래쉬로 짜달라고 한다. JSP 가 모든 것을 책임 지는 Model 1 방식 같으면 고객의 멱살을 잡고 그냥....은 절대 농담이고, 피똥싸며 야근하겠지만 Model 2 방식은 view 부분을 담당하는 쪽만 플래쉬로 바꿔주면 그만이다.
하지만 이렇게 좋은 Model 2도 단점이 존재하는데...
일단 Model 1 의 개발 방식보다 어렵다고들 한다. 그리고 시간도 많이 걸린다고 한다.
하지만 이 단점을 충분히 커버할 만한 유지보수 의 위대함 앞에서
Model 2 는 너무나 당연한 선택이겠지...
그럼 이제 본격적으로(응?????) Spring MVC 에 대해 포스팅 하고자 한다.
Spring MVC는 Spring 에서 제공하는 MVC 기반의 웹 프레임워크이다.
Anyframe 의 메뉴얼에는 Spring MVC 의 특징을 아래와 같이 소개한다.
--------------------------------------------------------------------------------------------------------
Spirng MVC 웹 프레임워크는 다음과 같은 특징을 가진다.
역할 분리가 명확하다. controller, validator, command 객체, 폼 객체, model 객체, DispatcherServlet, handler mapping, view resolver 등의 각각의 역할은 해당 역할 만을 전문으로 수행하는 객체들이 담당한다.
어플리케이션 내의 JavaBean들과 프레임워크에 관련된 설정이 쉽고 간단하다.
Business 객체를 Framework에 종속된 API를 사용하여 확장하지 않고도 command 또는 폼 객체로 재사용할 수 있다.
Application 레벨에서 데이터를 바인딩 하고 validation 에러를 체크할 수 있도록 데이터 바인딩 및 검증을 customizing 할 수 있다.
간단한 URL 기반 설정으로 다양한 handler mapping과 view resolution을 customizing 할 수 있다.
모델이 맵으로 구성되기 때문에 여러 view 기술과의 연계가 쉽다.
데이터 바인딩이나 테마 사용을 위한 spring 태그를 제공한다.
JSP의 입력 폼을 보다 쉽게 만들 수 있는 form 태그를 제공한다.
오늘의 가장 중요한 그림
위의 그림은 Spring MVC 에서 Request 를 처리하는 흐름을 나타낸 그림이다.
그 흐름을 모듈별로 본다면
- DispatcherServlet이 모든 요청을 받는다.
- HandlerMapping을 통해서 해당 요청을 처리할 Controller를 검색한다.
- Controller로 요청을 전달한다.
- Controller는 DB에서 처리된 결과(ModelAndView)를 리턴한다
- ViewResolver를 통해서 결과를 보여줄 View를 검색한다.
- View에게 응답을 출력할 것을 요청하고 View는 클라이언트에게 전송할 응답을 생성한다.
어떤가?
당신은 그림과 설명을 함께 보니 이해가 더 잘간다고 말을 하고 있다..........;;
포스팅이 끝을 향해 가고있다.
주요 구성 요소들을 설명하면서 이번 포스팅을 마칠까 한다.
-DispatcherServlet : 어플리케이션으로 들어오는 모든 Request를 받는 관문이다. Request를 실제로 처리할 Controller 에게 전달하고 그 결과값을 받아서 View에게 전달하여 적절한 응답등 생성할 수 있도록 흐름을 제어한다.
-HandlerMapping : Request URL 각각을 어떤 Controller 가 실제로 처리할 것인지 찾아주는 역할을 한다.
-Controller : Request를 직접 처리한 후 그 결과를 다시 DispatcherServlet 에게 돌려준다.
-ModelAndView : Controller가 처리한 결과와 그 결과를 보여줄 View에 관한 정보를 담고 있는 객체이다.
-ViewResolver : View 관련 정보를 갖고 실제 View를 찾아주는 역할을 한다.
-View : Controller가 처리한 결과값을 보여줄 View를 생성한다.
이것이 Spring MVC 의 간단(?)하게 설명한 구조이다.
소스를 포함한 자세한 설정법은
나중에 다시 포스팅 하겠다. 아니 하고싶다....
그 흐름을 모듈별로 본다면
- DispatcherServlet이 모든 요청을 받는다.
- HandlerMapping을 통해서 해당 요청을 처리할 Controller를 검색한다.
- Controller로 요청을 전달한다.
- Controller는 DB에서 처리된 결과(ModelAndView)를 리턴한다
- ViewResolver를 통해서 결과를 보여줄 View를 검색한다.
- View에게 응답을 출력할 것을 요청하고 View는 클라이언트에게 전송할 응답을 생성한다.
어떤가?
당신은 그림과 설명을 함께 보니 이해가 더 잘간다고 말을 하고 있다..........;;
포스팅이 끝을 향해 가고있다.
주요 구성 요소들을 설명하면서 이번 포스팅을 마칠까 한다.
-DispatcherServlet : 어플리케이션으로 들어오는 모든 Request를 받는 관문이다. Request를 실제로 처리할 Controller 에게 전달하고 그 결과값을 받아서 View에게 전달하여 적절한 응답등 생성할 수 있도록 흐름을 제어한다.
-HandlerMapping : Request URL 각각을 어떤 Controller 가 실제로 처리할 것인지 찾아주는 역할을 한다.
-Controller : Request를 직접 처리한 후 그 결과를 다시 DispatcherServlet 에게 돌려준다.
-ModelAndView : Controller가 처리한 결과와 그 결과를 보여줄 View에 관한 정보를 담고 있는 객체이다.
-ViewResolver : View 관련 정보를 갖고 실제 View를 찾아주는 역할을 한다.
-View : Controller가 처리한 결과값을 보여줄 View를 생성한다.
이것이 Spring MVC 의 간단(?)하게 설명한 구조이다.
소스를 포함한 자세한 설정법은
나중에 다시 포스팅 하겠다. 아니 하고싶다....