뷰가 없이 요청이 오면 응답을 줍니다. Servlet이긴 한데 뷰가 없는 애플리케이션입니다. Request로 받은 메시지를 가지고 어떤 비즈니스로직을 수행하고 그 결과를 Response로 담아서 전달해주면 요청을 보낸 쪽에서 그걸 받아서 또 다른 곳으로 전달합니다.

이 애플리케이션이 할 일은 주로 세 가지죠.

  1. 요청 받기
  2. 메시지를 객체로 파싱
  3. 비즈니스 로직 수행
  4. 결과를 메시지로 변환
  5. 응답으로 메시지 보내기

메시지/객체 변환은 다른 객체에게 위임해버리기로 하고, 비즈니스 로직도 다른 곳으로 위임해버리고 이 서브릿은 오로지 위와 같은 일의 순서를 정해둔 템플릿으로 사용하고 싶네요. 컨트롤러처럼 말이죠. 비즈니스 로직을 수행하는 녀석들은 모두 도메인 객체로 구현하고 메시지를 변환한 객체들은 DTO가 되겠죠.

그런데 문제는 메시지를 받는 쪽에서 이 메시지에 어떤 비즈니스 로직을 태워야 하는지 알 수가 없다는 것입니다. 따라서 파싱한 결과를 보고 판단해야합니다.

지금까지 분석한 내용으로 Spring MVC에 대입해서 생각해보겠습니다.

먼저 전달받는 녀석이 Dispatcher Servlet과 같은 문지기 역할을 합니다. 그리고 메시지를 파싱해주는 녀석을 통해서 메시지를 파싱하고 그 중에서도 어느 비즈니스 로직을 수행해야 하는지 결정하는 인자를 파악하여 Handler Mapper에게 어떤 컨트롤러가 해당 메시지를 처리해야 하는지 물어봅니다.

그 결과를 디스패처에게 알려주면, 디스패처는 다시 해당 컨트롤러에게 변환한 DTO를 인자로 넘겨주면서 처리를 부탁합니다. 그럼 컨트롤러에서 해당 DTO를 가지고 비즈니스 로직을 수행하고 그 결과를 디스패처에게 반환해줍니다.

디스패처는 결과를 받아서 DTO를 메시지로 다시 변환해주는 녀석에게 파싱을 부탁합니다. 그 결과(바이트스트림 메시지)를 응답에 태워서 보냅니다.

기존의 Spring MVC에서 View Resolving과 관련된 부분을 빼고 동일합니다.

구현해야 할 것은 크게 네 가지 입니다.

  1. 위와 같은 일을 해줄 Dispatcher Servlet(DispatcherServlet 소스코드 분석 후 뷰 렌더링 부분 수정)
  2. 메시지(바이트스트림)/객체의 변환을 맡을 객체(Interceptor로 처리할까?)
  3. 특정 정보를 가지고 그것을 처리할 컨트롤러를 매핑할 Handler Mapper(그냥 단순하게 key/value 쌍으로 호출해야할 컨트롤러 이름을 관리하는 클래스가 필요할 듯.)
  4. 비즈니스 로직을 수행할 컨트롤러들.(인터페이스 정도는 미리 설계해 둘 순 있겠군)

비즈니스 로직 수행할 녀석들은 나중에 만든다쳐도 1, 2, 3번 클래스들은 만들어야겠네요. 이게 제가 들어간 프로젝트에서 프레임워크가 해줄 부분 입니다. 흠냐~ 스프링써서 만들어두면 쓰시겠죠.