- jsp 가 너무 많은 일을 하는 것을 덜기 위해서 mvc가 등장했고, ui와 비즈니스 로직의 변경 라이프 사이클을 따로 관리하고 위해서 mvc가 필요했다.
- mvc 패턴은 하나의 서블릿이나 jsp로 처리하던 것을 컨트롤러와 뷰라는 영역으로 서로 역할을 나눈 것이다.
- 고객이 요청을 하면 컨트롤러가 비즈니스 로직을 수행하고, 모델에 데이터를 담은 후 뷰 로직을 수행한다. 그러면 뷰 로직이 모델의 데이터를 참고해 화면에 그린다.
- 컨트롤러는 http 요청을 받아 파라미터를 검증하고, 비즈니스 로직을 실행 한 후 모델에 데이터를 담는다.
- 모델은 뷰에 출력할 데이터를 담아둔다.
- 뷰는 모델에 담긴 데이터를 사용해 화면을 그린다. 즉 html을 생성한다.
- 일반적인 비즈니스 로직은 다음과 같다.
- 컨트롤러 로직이 http 요청이 제대로 됐는지 확인하고 서비스나 리포지토리를 호출해 로직을 실행하고 결과를 받아 모델에 데이터를 전달하는 구조다.
- 컨트롤러에 비즈니스 로직을 두면 역할이 너무 커지므로 비즈니스 로직은 서비스 계층을 따로 두고 컨트롤러가 비즈니스 로직을 호출하는 역할을 하는 것이 좋다.
### - mvc 패턴 적용
- request는 내부에 데이터 저장소를 가지고 있는데, request.setAttribute(), request.getAttribute()를 사용하면 데이터를 보관하고 조회할 수 있다.
- 컨트롤러로 사용할 클래스를 세팅해준다.
- 먼저 위 경로에 jsp를 하나 만들어주고 경로를 viewPath에 담는다
- request.getRequestDispather(viewPath)를 통해 컨트롤러에서 뷰로 이동하는 로직을 작성한다.
- dispather.forward()를 통해 jsp를 호출한다.
-
호출할 jsp 파일을 세팅하고 서버를 돌려 확인해준다.
-
WEB-INF 하위의 jsp 자원은 외부에서 불려지는 것이 아닌 항상 컨트롤을 거쳐 forward해 불려지는 자원들을 담는다.
-
redirect와 forward의 차이:
-
redirect는 실제 웹-서버로 응답이 나갔다가 클라이언트가 redirect로 다시 요청하는, 호출이 두 번 일어난다. 따라서 클라이언트가 인지할 수 있고, url경로가 변경된다.
-
반대로 forward는 클라이언트의 1회 요청 후 서버 내부에서만 일어나는 호출이므로 클라이언트가 인지하지 못하므로 클라이언트가 인지할 수 없다.
- 이제 회원 저장 컨트롤러를 생성해 보겠다. 먼저 컨트롤러를 세팅해준다.
- 먼저 모델에 데이터를 보관해야 한다. request 내부에 member 객체를 저장해준다.
- viewPath를 설정하고 해당 경로로 dispather를 forward한다.
- save-result.jsp를 만들어준다.
- ${member.id} 를 사용하면 프로퍼티 접근법이라 하여 자동으로 id를 get 해준다. request.getAttribute("member").getId와 같은 코드다.
- 이제 회원 목록을 조회해보겠다. 컨트롤러를 생성한다.
- findall을 통해서 멤버 객체를 전부 리스트에 담고, 이를 setAttribute를 통해 "member"라는 키로 request에 저장한다.
- 역시 경로 생성 후 dispatcher로 포워드해준다.
- members.jsp 파일을 생성해준다.
- 위 태그를 추가하면 다양한 루프문을 쉽게 작성할 수 있다.
- 위 c:forEach 태그는 루프를 돌면서 members 리스트의 객체를 하나씩 가져오며 객체를 출력해준다.
-
이제 회원 목록이 정상적으로 출력된다.
-
MVC 덕분에 컨트롤러와 뷰의 역할을 명확하게 구분했다. 그러나 컨트롤러에서 디스패쳐로 포워드하는 코드 등을 보면 계속 중복/반복되는 모습이 보인다. 이러한 한계가 존재한다.
하마드