

긴 연휴 동안 김영한 스프링 MVC 강의를 예습과 복습을 겸하여서 들었다. 서블릿에서 시작해 JSP와 MVC, 프론트 컨트롤러, 스프링 MVC 구조까지 한 흐름으로 연결해 보았다.
단일 진입점 패턴의 효과
공통 로직을 한곳에서 처리할 수 있어 로깅, 에러 처리, 인증같은 관심사를 일관되게 적용할 수 있다.
뷰와 컨트롤러의 역할 분리
컨트롤러는 모델 준비와 흐름 제어에 집중하고, 뷰는 화면 렌더링에만 집중한다. 뷰 경로 하드코딩 대신 뷰 리졸버로 논리 이름을 물리 경로로 치환한다.
핸들러 어댑터를 통한 확장성
컨트롤러 모양이 달라도 어댑터가 중개하면 구조를 바꾸지 않고 확장할수 있다.
HTTP 의존 최소화
요청과 응답 객체에 직접 의존하는 코드를 줄이면 테스트가 단순해진다.
포워드와 리다이렉트의 기준
조회 계열은 포워드, 상태 변경 후에는 리다이렉트를 사용하면 흐름과 사용자 경험이 명확해진다.
서블릿 기본기 정리
요청 인코딩, 콘텐츠 타입, 헤더와 쿠키, 세션 흐름을 코드 전에 먼저 설정한다.
JSP와 MVC 적용
뷰는 보호 경로 아래에 두고, 컨트롤러는 모델을 채워 포워드한다. 뷰는 EL과 JSTL로 렌더링만 담당한다.
프론트 컨트롤러 구조
핸들러 매핑과 어댑터, 뷰 리졸버로 공통 처리를 표준화한다.
스프링 MVC 요청 처리 단계
디스 패처 서블릿이 핸들러를 찾고, 어댑터가 실행을 중개하며, 모델과 뷰 정보를 바탕으로 리졸버와 뷰가 최종 렌더링한다.
애노테이션 기반 컨트롤러
메서드 단위 매핑, 모델 파라미터 주입, 논리 뷰명 반환으로 컨트롤러 코드를 단순하게 유지한다.
서블릿에서 시작해 MVC 패턴과 프론트 컨트롤러, 스프링 MVC 구조까지 이어지는 설계 의도를 확인할 수 있었다.
아직 스프링은 이해되지 않는 부분이 많은 것 같아서, 해당 내용은 다시 수업을 병행해 가면서 다듬어 나가야 할 것 같다.
다음주부터는 새로운 조가 정해지고 본격적으로 벡엔드 프로젝트가 시작된다는데 기대 반, 걱정 반인 것 같다.
특히, 공모전 프로젝트와 같이 진행되는 만큼, 많이 힘들어질 것 같다.