스프링 MVC는 스프링의 서브 프로젝트이다.
스프링 MVC를 구성해서 사용한다는 의미는 내부적으로는 root-context.xml로 사용하는 일반 Java 영역(POJO)과 servlet-context.xml로 설정하는 Web 관련 영역을 같이 연동해서 구동하게 된다.
로딩 구조 : 프로젝트 구동시 web.xml은 Tomcat 관련 설정, root-context.xml과 servlet-context.xml은 스프링 관련 설정이다.
스프링 MVC를 이용하면 Servlet/JSP의 API (HttpServletRequest, HttpServletResponse)등을 작성안하고도 기능 구현이 가능하다.
사용자의 Request는 Front-Controller인 DispatcherServlet을 통해서 처리.
HandlerMapping은 Request의 처리를 담당하는 컨트롤러를 찾기 위해 존재.
컨트롤러가 찾아졌다면 Handler Adapter를 이용해서 해당 컨트롤러를 작동.
컨트롤러는 개발자가 작성하는 클래스로 실제 Request를 처리하는 로직을 작성하게 된다. 이때 View에 전달하는 데이터는 주로 Model이라는 객체에 담아 전달, 컨트롤러는 다양한 타입의 결과를 반환하는데 이에 대한 처리는 ViewResolver를 이용.
ViewResolver는 컨트롤러가 반환한 결과를 어떤 View를 통해서 처리하는 것이 좋을지 해석하는 역할.
View는 실제로 응답 보내야 하는 데이터를 JSP 등을 이용해서 생성하는 역할을 하게 된다. 만들어진 응답은 DispatcherServlet을 통해서 전송.
컨트롤러의 메서드가 사용할 수 있는 리턴타입
하나의 클래스 내에서 여러 메서드를 작성하고, @RequestMapping등을 이용해서 URL을 분기하는 구주로 작성할 수 있기 때문에 하나의 클래스에서 필요한 만큼 메서드의 분기를 이용하는 구조로 작성한다.
특징 :
Model 객체는 JSP에 컨트롤러에서 생성된 데이터를 담아서 전달하는 역할을 하는 존재. Model을 사용해야 하는 경우는 주로 Controller에 전달된 데이터를 이용해서 추가적인 데이터를 가져와야 하는 상황.
(ex: 리스트 페이지 번호를 파라미터로 전달 받고, 실제 데이터를 View로 전달해야 하는경우, 파라미터들에 대한 처리 후 결과를 전달해야 하는 경우)
@ModelAttribute 는 강제로 전달 받은 파라미터를 Model에 담아서 전달하도록 할 때 필요한 어노테이션. 타입에 관계없이 무조건 Model에 담아서 전달되므로, 파라미터로 전달된 데이터를 다시 화면에서 사용해야 할 경우에 유용하게 사용된다.
RedirectAttributes는 Model과 같이 파라미터로 선언해서 사용하고, 일회성 데이터를 전달하는 용도로 사용된다.
@ExceptionHandler : 해당 메서드가 () 들어가는 예외 타입을 처리한다는 것을 의미. 속성으로는 Exceoption 클래스 타입을 지정할 수 있다.
@ControllerAdvice : AOP(Aspect-Oriented-Programming)을 이용하는 방식, 공통적인 예외사항에 대해서는 별도로 분리 하는 방식.
서블릿이나 JSP를 이용했던 개발 시에는 web.xml을 이용해서 별도의 에러 페이지를 지정할 수 있다. 에러 발생 시 추가적인 작업을 하기는 어렵기 때문에 스프링을 이용해서 404와 같이 WAS 내부에서 발생하는 에러를 처리하는 방식을 알아두는게 좋다.
일반적으로 웹 프로젝트는 3-tier(티어) 방식으로 구성한다.
Presentation <--> Business <--> Persistence tier
Presentation Tier(화면 계층)는 화면에 보여주는 기술을 사용하는 영역.(Servlet/JSP나 스프링 MVC)
Business Tier(비즈니스 계층)는 순수한 비즈니스 로직을 담고 있는 영역. 고객이 원하는 요구 사항을 반영하는 계층. (주로 'xxxService'와 같은 이름으로 구성, 메서드의 이름 역시 고객들이 사용하는 용어를 그대로 사용 하는게 좋다)
Persistence Tier(영속 계층)는 데이터를 어떤 방식으로 보관하고, 사용하는가에 대한 설계가 들어가는 계층이다. 일반적으로는 데이터베이스를 많이 이용하지만, 경우에 따라 네트워크 호출이나 원격 호출등의 기술이 접목될 수 있다.
Controller : URL을 통해 온 요청을 받고 Response.
(@RequestMapping-요청URL분류, @RestController-역할 명시)
Service : Controller를 통해 온 요청을 받고 비즈니스 로직 구현 하고 다시 전달 === 여러 Dao를 호출하여 여러번의 데이터 처리를 하며 읽은 데이터에 대한 비즈니스 로직 수행 or 여러개의 트랜잭션으로 묶음
(@Service-역할 명시, @Transactional-트랜잭션단위, for 구분을 통해 DB와 insert/update/delete 할 시 한개라도 동작에 실패하면 그전에 수행되었던 로직도 원복시키는 단위)
Mapper : Mybatis 영역, java interface와 xml로 구성
java interface (@Mapper-역할 명시)
xml (SQL 쿼리문, namespace 통해 java interface와 연동)
DTO : Data Transfer Object, 각 계층간 데이터 교환을 위한 객체. VO와 동일하게 데이터를 저장하여 사용하도록 하는 부분에 필요. 비즈니스 로직을 담아 사용하기도 한다.
DAO : DB 테이블과 같으며 DB를 통해 조회환 값을 가져오기 위한 객체. DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담.
VO : 데이터 그 자체로 의미 있는 것을 담고 있는 객체. DTO와 동일한 개념이지만 차이점은 Read-only 속성 객체.