1. 서블릿 텍스트필터

1-1. 필터

• HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러 -> 비즈니스 로직...

1-2. 필터 체인텍스트

• HTTP 요청 -> WAS -> 필터1 -> 필터2 -> 필터3 -> ... -> 서블릿 -> 컨트롤러 -> ...
• 필터는 체인으로 구성되는데, 중간에 필터를 자유롭게 추가할 수 있다.
• 예를 들어 로그를 남기는 필터를 먼저 적용하고 그 다음에 로그인 여부를 체크하는 필터를 만들 수 있다.

1-3. 필터 구현

• 필터 인터페이스를 구현하고 등록하면 서블릿 컨테이너가 필터를 싱글톤 객체로 생성하고 관리한다.
• init() : 필터 초기화 메서드, 서블릿 컨테이너가 생성될 때 호출된다.
• doFilter() : 고객의 요청이 올 때마다 해당 메서드가 호출된다.
• 필터의 로직을 구현하면 된다.
• destroy() : 필터 종료 메서드, 서블릿 컨테이너가 종료될 때 호출된다.

2. 스프링 인터셉터

2-1. 인터셉터란?

• 스프링 인터셉터도 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 있는 기술이다.
• 서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다.
• 둘 다 웹과 관련된 공통 관심 사항을 처리하지만, 적용되는 순서와 범위, 사용방법이 다르다.

2-2. 스프링 인터셉터 흐름

• HTTP요청 -> WAS -> 필터 -> 서블릿 요청 -> 스프링 인터셉터 -> 컨트롤러
• 스프링 인터셉터는 디스패처 서블릿과 컨트롤러 사이에서 컨트롤러 호출 직전에 호출된다.
• 스프링 인터셉터는 스프링 MVC가 제공하는 기능이기 때문에 결국 디스패처 서블릿 이후에 등장하게 된다.
• 스프링 MVC의 시작점이 디스패처 서블릿이라고 생각하면 이해가 빠르다.
• 스프링 인터셉터에도 URL 패턴을 적용할 수 있는데, 서블릿 URL 패턴과는 다르고 매우 정밀하게 설정할 수 있다.

2-3. 스프링 인터셉터 체인

• HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 인터셉터1 -> 인터셉터2 -> ... -> 컨트롤러
• 스프링 인터셉터는 체인으로 구성되는데, 중간에 인터셉터를 자유롭게 추가할 수 있다.
  -스프링 인터셉터는 서블릿 필터보다 편리하고, 더 정교하고 다양한 기능을 지원한다.

2-4. 인터셉터 인터페이스

• HandlerInterceptor 인터페이스를 구현
• 서블릿 필터의 경우 단순하게 doFilter()하나만 제공된다.
• 인터셉터는 호출 전(preHandle), 호출 후(postHandle), 요청 완료 이후(afterCompletion) 같이 단계적으로 잘 세분화 되어 있다.
• 서블릿 필터의 경우 단순히 request, response만 제공했지만, 인터셉터는 어떤 컨트롤러가 호출 되는지 호출 정보도 받을 수 있다.

2-5. addPathPatterns("/**")

• 2개의 페이지에 대해 중복하여 interceptor를 쓰려면
  addPathPatterns("/sub1/test1", "/sub1/test2")를 사용한다.
• 1개의 어떠한 경로에 상관없이 쓰려면
  addPathPatterns("/*")를 사용한다.
• 1개를 넘어서서 몇 개의 어디든지의 경로에 추가하고 싶으면
  addPathPatterns("/**")를 사용한다.

3. ORM

3-1. ORM이란?

• Object-Relational Mapping (객체 관계 매핑)
• 객체는 객체대로 설계
• 관계형 데이터베이스는 관계형 데이터베이스대로 설계
• ORM 프레임워크가 중간에서 매핑
• 대중적인 언어는 대부분 ORM 기술이 존재
• 우리가 일반적으로 알고있는 어플리케이션 Class와 RDB(Relational DataBase)의 테이블을 매필(연결)한다는 뜻이며, 기술적으로는 어플리케이션의 객체를 RDB테이블에 자동으로 영속화 해주는 것이라고 보면된다.

3-2. 장점

• SQL문이 아닌 Method를 통해 DB를 조작할 수 있어서 개발자는 객체 모델을 이용하여 비즈니스 로직을 구성하는데에만 집중할 수 있다.
• Query와 같이 필요한 선언문, 할당 등의 부수적인 코드가 줄어들어 각종 객체에 대한 코드를 별도로 작성하여 코드의 가독성을 높임.
• 객체 지향적인 코드 작성이 가능하다.
• 오직 객체 지향적인 접근만 고려하면 되기 때문에 생산성이 증가한다.
• 매핑하는 정보가 Class로 명시 되었기 떄문에 ERD를 보는 의존도를 낮출 수 있고 유지보수 및 리팩토리에 유리하다.
• MySQL로 데이터베이스를 사용하다가 PostgreSQL로 변환한다고 가정해보면 새로 쿼리를 짜야하는 경우가 생기는데, 이런 경우에 ORM을 사용한다면 쿼리를 수정할 필요가 없다.

3-3. 단점

• 프로젝트 규모가 크고 복잡하여 설계가 잘못된 경우, 속도 저하 및 일관성을 무너뜨리는 문제점이 생길 수 있다.
• 학습 비용이 비싸다.(시간투자, 비용 등등)
• 복잡하고 무거운 Query는 속도를 위해 별도의 튜닝이 필요하기 때문에 결국엔 SQL문을 써야할 수도 있다.