[Spring] Exception 처리, 스프링 MVC 프로젝트의 기본 구성(3-tier)

1. Exception 처리

• 백단에서의 예외 처리
• AOP(관점 지향 프로그래밍)
• 각 요청마다 예외 처리를 해주는 것이 아니라 하나로 묶어서 다른 곳으로 보내줘서 예외 처리를 해준다.

2. @ControllerAdvice

• 예외 사항을 전부 매번 마다 핸들링해야 한다면 중복적이고 많은 양의 코드를 작성해야 하지만, 공통적인 예외사항에 대해서는 별도로 @ControllerAdvice를 이용해서 분리한다. AOP를 이용하는 방식

• 백단, 즉 Controller에서 문제가 생기거나 예외가 발생하면 예외 처리를 이 클래스에서 한다는 것을 어노테이션을 통해 명시를 해준다.(@ControllerAdvice)
• 그렇게 하기 위해서는 root-context.xml 에다가 미리 예외가 발생하면 이 클래스로 오라고 길을 미리 알려주는 설정을 해줘야 한다.

root-context.xml

• 이제 예외가 발생하면 이 클래스로 오게 된다.

3. @ExceptionHandler()

• 발생하는 예외를 타입별로 흐름을 나눠줄 때 사용하는 매핑 방식
• 예외가 발생해서 이 클래스로 오면 @ExceptionHandler("예외 클래스")로 흐름을 나눠준다.
  
  

CommonExceptionAdvice

• 예외 클래스가 어노테이션으로 된 곳을 찾아가서 그 메소드를 실행하게 된다.
• 그때 메소드의 매개변수로 예외 객체를 받을 수 있고, Model 객체를 매개변수로 둬서 원하는 페이지에다가 값들을 보내줄 수 있다.
• 예외가 발생하면 이제는 에러 페이지로 보내줘서 예외 처리를 할 수 있다. 컨트롤러에서 요청에 따라 나눠서 페이지를 이동해주는 것처럼 예외 처리 페이지 이동도 방식은 같다.

view

• Model 객체로 보낸 exception을 이용해서 stactTrace를 하나하나씩 for문을 이용해서 출력해주면 옆에와 같이 오류 정보들을 출력해주며 이제 예외 처리를 하나의 클래스에서 관리를 함으로써 편리하게 할 수 있다.

4. 404 오류 일 때(URL이나 URI를 잘못 호출했을 때)

• 500 메시지는 문법 오류 발생 시 @ExceptionHandler를 이용해서 처리가 가능했지만, 404 메시지는 오류가 아닌 URL, URI를 잘못 호출했을 때 처리해야 한다.
• 따라서 DispatcherServlet이 web.xml에 간 후 어디로 가야 할지 모를 때 NoHandlerFoundException을 발생 시키도록 설정을 해놓고, 실제로 매핑을 못 찾았을 때 그 예외가 발생되고, 예외가 발생시 우리가 만든 예외 처리하는 클래스(CommonExceptionAdvice.java)에서 잡아주면 된다.
• 그렇게 되면 404 메시지 대신에 원하는 페이지로 응답할 수 있게 된다.

web.xml

CommonExceptionAdvice.java

view

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

- 스프링 MVC에서 어떤 단계를 거쳐서 실행되는지를 이해해야 문제 발생 시 빠른 대처와 대안을 찾을 수 있다.

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

 

Persistence <-> Business <-> Presentation

 

• Persistence Tier(영속 계층, 데이터 계층)
  - 데이터를 어떤 방식으로 보관하고, 사용하는가에 대한 설계가 들어가는 계층
  - 일반적으로는 DB를 많이 이용하지만, 상황에 따라서 네트워크 호출 혹은 원격 호출 등의 기술이 접목함
• Business Tier(비즈니스 계층)
  - 순수한 비즈니스 로직을 담고 있는 영역
  - 고객이 원하는 요구사항을 반영하는 계층이기 때문에 중요한 영역
  - 이 영역의 설계는 고객의 요구 사항과 정확히 일치해야 하며, '~~ Service'와 같은 이름으로 구성
• Persentation Tier(화면 계층)
  - 화면에 보여주는 기술을 사용하는 영역
  - JSP/Servlet 혹은 스프링 MVC가 담당하는 영역이며 화면 구성이 이에 속함

[결론]

1. 영속 계층에서 여러 개의 메소드를 만들어 놓고 비즈니스 계층에서 호출해서 적절한 배치를 통해 비즈니스 로직을 짠다.
2. 각 영역은 독립적으로 설계되어 나중에 특정한 기술이 변하더라도 필요한 부분을 전자제품의 부품처럼 쉽게 교환할 수 있게 하자는 방식이다.
3. 각 연결 부위는 인터페이스를 이용해서 설계하는 것이 일반적인 구성 방법이다. 하지만 다른 방법도 또한 가능하다.