Spring MVC

젤로·2022년 8월 16일
0

Java

목록 보기
3/7

✔ 스프링 MVC

  • 스프링 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)등을 작성안하고도 기능 구현이 가능하다.


✔ 스프링 MVC의 기본 구조

  • MVC는 모델2 방식으로 처리 : '로직과 화면을 분리' - 사용자의 Request는 Controller를 먼저 호출 (나중에 View를 교체하더라도 사용자가 호출하는 URL자체에 변화가 없게 만들어주기 위해), 컨트롤러는 데이터를 처리하는 존재를 이용해서 데이터(Model)를 처리하고 Response할 때 필요한 데이터(Model)를 View쪽으로 전달한다.
  1. 사용자의 Request는 Front-Controller인 DispatcherServlet을 통해서 처리.

  2. HandlerMapping은 Request의 처리를 담당하는 컨트롤러를 찾기 위해 존재.

  3. 컨트롤러가 찾아졌다면 Handler Adapter를 이용해서 해당 컨트롤러를 작동.

  4. 컨트롤러는 개발자가 작성하는 클래스로 실제 Request를 처리하는 로직을 작성하게 된다. 이때 View에 전달하는 데이터는 주로 Model이라는 객체에 담아 전달, 컨트롤러는 다양한 타입의 결과를 반환하는데 이에 대한 처리는 ViewResolver를 이용.

  5. ViewResolver는 컨트롤러가 반환한 결과를 어떤 View를 통해서 처리하는 것이 좋을지 해석하는 역할.

  6. View는 실제로 응답 보내야 하는 데이터를 JSP 등을 이용해서 생성하는 역할을 하게 된다. 만들어진 응답은 DispatcherServlet을 통해서 전송.


✔ 스프링 MVC의 Controller

컨트롤러의 메서드가 사용할 수 있는 리턴타입
하나의 클래스 내에서 여러 메서드를 작성하고, @RequestMapping등을 이용해서 URL을 분기하는 구주로 작성할 수 있기 때문에 하나의 클래스에서 필요한 만큼 메서드의 분기를 이용하는 구조로 작성한다.

  • String : jsp를 이용하는 경우에는 jsp파일의 경로와 파일이름을 나타내기 위해 사용
  • void : 호출하는 URL과 동일한 이름의 jsp를 의미
  • VO, DTO 타입 : 주로 JSON 타입의 데이터를 만들어서 반환하는 용도로 사용
  • ResponseEntity 타입 : Response할때 Http 헤더 정보와 내용을 가공하는 용도로 사용
  • HttpHeaders : 응답에 내용 없이 Http 헤더 메시지만 전달하는 용도로 사용

특징 :

  • HttpServletRequest, HttpServletResponses를 거의 사용할 필요 없이 필요한 기능 구현
  • 다양한 타입의 파라미터 처리, 다양한 타입의 리턴 타입 사용 가능
  • GET 방식, POST 방식 대신에 어노테이션만으로도 필요한 설정 가능
  • 기본적으로 Java Beans 규칙에 맞는 객체는 다시 화면으로 객체를 전달.
  • 어노테이션 :
    @Data 어노테이션으로 getter/setter, equals(), toString()등의 메서드를 자동 생성한다.
    @RequestMapping 어노테이션으로 method속성을 추가 할 수 있다. method 속성은 흔히 GET 방식, POST 방식을 구분해서 사용할 때 이용한다.
    @RequestParam 어노테이션은 파라미터로 사용된 변수의 이름과 전달되는 파라미터의 이름이 다른 경우 유용하게 사용할 수 있다.
    @InitBinder 변환이 가능한 데이터는 자동으로 변환되지만 경우에 따라서는 파라미터를 변환해서 처리해야 하는 경우도 있다. 이때 사용하는게 InitBinder 어노테이션.

✔ 스프링 MVC의 Model

Model 객체는 JSP에 컨트롤러에서 생성된 데이터를 담아서 전달하는 역할을 하는 존재. Model을 사용해야 하는 경우는 주로 Controller에 전달된 데이터를 이용해서 추가적인 데이터를 가져와야 하는 상황.
(ex: 리스트 페이지 번호를 파라미터로 전달 받고, 실제 데이터를 View로 전달해야 하는경우, 파라미터들에 대한 처리 후 결과를 전달해야 하는 경우)

@ModelAttribute 는 강제로 전달 받은 파라미터를 Model에 담아서 전달하도록 할 때 필요한 어노테이션. 타입에 관계없이 무조건 Model에 담아서 전달되므로, 파라미터로 전달된 데이터를 다시 화면에서 사용해야 할 경우에 유용하게 사용된다.

RedirectAttributes는 Model과 같이 파라미터로 선언해서 사용하고, 일회성 데이터를 전달하는 용도로 사용된다.


✔ Controller의 예외 처리

@ExceptionHandler : 해당 메서드가 () 들어가는 예외 타입을 처리한다는 것을 의미. 속성으로는 Exceoption 클래스 타입을 지정할 수 있다.
@ControllerAdvice : AOP(Aspect-Oriented-Programming)을 이용하는 방식, 공통적인 예외사항에 대해서는 별도로 분리 하는 방식.


✔ 404 에러 페이지

서블릿이나 JSP를 이용했던 개발 시에는 web.xml을 이용해서 별도의 에러 페이지를 지정할 수 있다. 에러 발생 시 추가적인 작업을 하기는 어렵기 때문에 스프링을 이용해서 404와 같이 WAS 내부에서 발생하는 에러를 처리하는 방식을 알아두는게 좋다.


✔ 스프링 MVC 프로젝트의 기본 구성

일반적으로 웹 프로젝트는 3-tier(티어) 방식으로 구성한다.

Presentation <--> Business <--> Persistence tier

  • Presentation Tier(화면 계층)는 화면에 보여주는 기술을 사용하는 영역.(Servlet/JSP나 스프링 MVC)

  • Business Tier(비즈니스 계층)는 순수한 비즈니스 로직을 담고 있는 영역. 고객이 원하는 요구 사항을 반영하는 계층. (주로 'xxxService'와 같은 이름으로 구성, 메서드의 이름 역시 고객들이 사용하는 용어를 그대로 사용 하는게 좋다)

  • Persistence Tier(영속 계층)는 데이터를 어떤 방식으로 보관하고, 사용하는가에 대한 설계가 들어가는 계층이다. 일반적으로는 데이터베이스를 많이 이용하지만, 경우에 따라 네트워크 호출이나 원격 호출등의 기술이 접목될 수 있다.

  • Spring MVC 영역은 Presentation Tier를 구성하게 되는데, 각 영역은 별도의 설정을 가지는 단위로 볼 수 있다.
  • 스프링 Core 영역은 흔히 POJO의 영역이다. 스프링의 의존성 주입을 이용해서 객체 간의 연관구조를 완성해서 사용한다.
  • Mybatis 영역은 mybatis-spring을 이용해서 구성하는 영역이다. SQL에 대한 처리를 담당하는 구조이다.

✔ MVC 구조 예시

  • 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 속성 객체.


profile
Back-End Developer 🍏🍎

0개의 댓글

관련 채용 정보