프론트 컨트롤러(DispatcherServlet)

프론트 컨트롤러 패턴 

• 도입 전 : 공통로직 => 각 컨트롤러 (공통로직이 계속 반복됨)
• 도입 후 : 프론트 컨트롤러 => 각 컨트롤러 (하나의 프론트 컨트롤러로 반복 사용 가능)

 

 FrontController 특징

• 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음
• 프론트 컨트롤러가 요청에 맞는 컨트롤러 찾아서 호출
• 입구를 하나로 통합하여 공통 처리
• 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨  

 

Spring Web MVC와 FrontController

• 스프링 웹 MVC의 핵심이 FrontController
• DispatcherServlet이 FrontController 패턴으로 구현되어있음

 

요청 처리 단계

• 클라이언트 HTTP 요청
• FrontController(DispatcherServlet)가 받아서 HandlerMapping에 해당 url과 매핑되어 있는 컨트롤러 정보 요청
• FrontController에서 받아온 컨트롤러 정보로 해당 컨트롤러 호출
• 비지니스 로직 수행 후 컨트롤러로 반환
• 컨트롤러에서 응답값 + View 정보 담아서 FrontController(DispatcherServlet)로 반환
• FrontController(DispatcherServlet)에서 반환 받은 응답값 ViewResolver로 전달 
• ViewResolver에서 view 정보 반환
• 반환 받은 정보를 클라이언트로 전송

 

Java에서 Servlet 생성 시 private static final long serialVersionUID = 1L; 선언 권장

Serialization 이란?

1) 모든 데이터의 흐름은 바이트 전송으로 이루어진다.

2) 이것은 객체도 마찬가지인데, Servlet 객체를 tomcat에게 전달할 때 Servlet 객체의 전송이 바이트 전송으로 이루어지게 된다.

3) Java 클래스는 Byte 형태로 전송되는 데이터를 직렬화 하기 위해 Serialization 이라는 형태를 사용하는데, java.io.Serializable 이라는 interface를 상속받아 처리된다.

=> 이 인터페이스는 HttpServlet이 상속받는다.

4) java.io.Serializable 인터페이스를 상속받은 후에는 static final long 타입의 serialVersionUID 상수 선언이 요구 되는데, 이는 java.io.Serializable를 상속받는 하위 클래스들에게도 요구된다.

​​

serialVersionUID 용도는?

1) 만일 serialVersionUID를 지정하지 않으면 실행시점에서 JVM이 디폴드 값을 산정하게 되며, 그 알고리즘은 Java(TM) Object Serialization Specification에 정의된 것을 따른다고 한다.

2) 한마디로 굳이 신경 쓸필요는 없다는 뜻이지만 모든 serialization이 필요한 클래스에는 명시적으로 serialVersionUID를 선언해줄것을 강력하게 권유하고 있다.

=> 그 이유는 디폴드 serialVersionUID 계산은 클래스의 세부 사항을 매우 민감하게 반영하기 때문에 컴파일러 구현체에 따라서 달라질 수 있어, deserialization(serialization 했던 객체를 복구하는 과정) 과정에서 예상하지 못한 예외를 유발할 수 있기 때문이다.

3) 서로 다른 자바 컴파일러 구현체 사이에서도 동일한 serialVersionUID값을 얻기 위해서는 명시적으로 serialVersionUID값을 선언해야 하며 가능한 serialVersionUID을 private으로 선언해야 한다.

 

참조 블로그