백엔드 개발자, 나단

이번 편에서는 스프링 MVC가 HTTP 요청에서 데이터를 읽어오는 다양한 방법을 정리한다.단순히 URL과 매핑하는 것에서 나아가, 헤더·쿼리 파라미터·폼 데이터·JSON을 어떻게 받아올 수 있는지, 그리고 이를 객체로 바인딩하는 방법까지 다룬다.1. HTTP 요청과 헤더 조회RequestHeaderController 예시@Slf4j@RestControllerpublic class RequestHeaderController { @RequestMapping("/headers") public String headers(HttpServletRequest request, HttpServletResponse response, ..

이번 편에서는 스프링 MVC에서 클라이언트 요청 URL과 컨트롤러 메서드를 연결하는 방법을 다룬다.단순히 @RequestMapping 하나만 아는 것과, 다양한 속성과 어노테이션의 의미를 깊게 이해하는 것은 큰 차이가 있다. 실무에서는 이 매핑 설정이 잘못되면 API 호출이 아예 불가능해지거나, 잘못된 응답을 반환하는 경우가 생기므로 반드시 확실히 알아둬야 한다.1. @RequestMapping 기본 사용@RestControllerpublic class MappingController { private final Logger log = LoggerFactory.getLogger(getClass()); @RequestMapping("/hello-basic") public String hel..

이번 편에서는 우리가 직접 만들었던 MVC 프레임워크와 스프링 MVC의 구조를 비교하고, 스프링 MVC가 어떻게 요청을 처리하는지 흐름을 단계별로 살펴본다. 특히 DispatcherServlet을 중심으로 한 핵심 컴포넌트, 인터페이스 구조, 그리고 실무에서 주로 사용하는 컨트롤러 작성 방식을 정리한다.1. 스프링 MVC 전체 구조 우리가 만든 MVC 프레임워크는 FrontController, handlerMappingMap, MyHandlerAdapter 등을 사용했는데, 스프링 MVC에서는 이를 다음과 같이 확장·구체화한다.직접 구현Spring MVCFrontControllerDispatcherServlethandlerMappingMapHandlerMappingMyHandlerAdapterHandle..

이번 글에서는 프론트 컨트롤러 패턴을 기반으로, v1 → v5까지 프레임워크가 점진적으로 발전하는 과정을 한 번에 정리한다.이 과정을 이해하면 스프링 MVC의 핵심 구조와 발전 방향이 한눈에 들어오고, 실제 프로젝트에서 확장성 있는 아키텍처를 설계할 때 큰 도움이 된다.1. v1 - 프론트 컨트롤러 도입목표기존 여러 서블릿을 하나의 입구(Front Controller)로 통합.공통 처리 로직을 한 곳에서 관리.특징ControllerV1 인터페이스를 만들고, 모든 컨트롤러가 이를 구현.URL 매핑(controllerMap)을 통해 어떤 요청이 어떤 컨트롤러로 갈지 결정.JSP forward 로직은 각 컨트롤러에서 직접 처리.장점요청 입구 단일화 → 공통 기능(로그, 인증 등) 처리 용이.유지보수성 향상.한..

1. 문제 상황현재 프론트 컨트롤러는 한 가지 인터페이스(v3, v4 중 하나)만 처리 가능.v3 방식, v4 방식을 동시에 지원하려면?2. 해결 아이디어어댑터 패턴 도입.프론트 컨트롤러는 컨트롤러를 직접 실행하지 않고, 핸들러 어댑터를 통해 실행.어댑터는 특정 컨트롤러 형태(v3, v4 등)에 맞게 호출 로직 변환.3. 핵심 구조public interface MyHandlerAdapter { boolean supports(Object handler); ModelView handle(HttpServletRequest request, HttpServletResponse response, Object handler);} supports(): 해당 컨트롤러를 처리할 수 있는지 판단.handle():..

1. v3의 한계컨트롤러가 ModelView 객체를 매번 직접 생성해야 함 → 약간 번거롭다.2. 개선 아이디어모델은 파라미터로 전달, 컨트롤러는 단순히 논리 뷰 이름만 반환.프론트 컨트롤러가 모델 객체를 미리 생성 후 컨트롤러에 전달.3. 핵심 구조public interface ControllerV4 { String process(Map paramMap, Map model);} 반환값: 뷰 이름(String)model 파라미터: 프론트 컨트롤러가 미리 생성해서 제공.4. 실행 흐름프론트 컨트롤러가 model을 생성 후 컨트롤러에 넘김.컨트롤러는 model에 데이터 추가 후 뷰 이름 반환.프론트 컨트롤러가 뷰 리졸버 → MyView로 렌더링.5. 회고v3보다 훨씬 개발자가 작성하기 편리했다.뷰 이름..

1. v2의 한계컨트롤러가 여전히 HttpServletRequest에 직접 접근해야 함.뷰 경로에 /WEB-INF/views/ 같은 물리 경로를 매번 적어야 함.2. 개선 아이디어Servlet 종속성 제거: 요청 파라미터를 Map으로 전달.Model 객체 분리: 데이터 전달을 위한 Map를 사용.뷰 이름 논리화: 컨트롤러는 "new-form"처럼 논리 이름만 반환 → 실제 경로는 프론트 컨트롤러가 처리.3. 핵심 구조public interface ControllerV3 { ModelView process(Map paramMap);}public class ModelView { private String viewName; private Map model = new HashMap(); /..

1. v1의 문제점모든 컨트롤러에서 뷰로 이동하는 forward 코드가 반복됨.String viewPath = "/WEB-INF/views/new-form.jsp";RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);dispatcher.forward(request, response);같은 코드가 3곳 이상 반복 → 유지보수에 불편.2. 개선 아이디어뷰 이동 로직을 공통 객체(MyView)로 분리.컨트롤러는 단순히 뷰의 경로를 가진 MyView 객체만 반환하면 된다.3. 핵심 구조public interface ControllerV2 { MyView process(HttpServletRequest request, HttpServl..

이번 편에서는 프론트 컨트롤러 패턴을 도입해보며, 스프링 MVC의 핵심 구조가 어떻게 만들어지는지 기초부터 살펴본다. 1. 프론트 컨트롤러란?입구를 하나로: 하나의 서블릿(FrontControllerServlet)이 모든 요청을 받는다.요청을 분석하여 알맞은 컨트롤러를 찾아 호출한다.공통 로직(로그, 인증, 예외처리 등)을 한 곳에서 처리할 수 있다.스프링 MVC의 DispatcherServlet이 이 패턴을 구현하고 있다.2. V1 구조ControllerV1 인터페이스를 만들어 모든 컨트롤러가 이를 구현하도록 한다.각 컨트롤러는 서블릿과 비슷하게 HttpServletRequest, HttpServletResponse를 받아 처리.프론트 컨트롤러는 URL 매핑(controllerMap)으로 어떤 요청이 ..

이번 편에서는 서블릿 → JSP → MVC로 이어지는 흐름을 실제 회원 관리 웹 애플리케이션 예제를 통해 단계별로 살펴본다.서블릿과 JSP를 비교하며, 왜 MVC 패턴이 등장하게 되었는지, 그리고 이를 적용하면 어떤 구조적 장점이 생기는지를 알아본다.1. 회원 관리 웹 애플리케이션 요구사항기능 요구사항회원 저장회원 목록 조회도메인 모델public class Member { private Long id; private String username; private int age; // 기본 생성자, getter/setter, 생성자...}회원 저장소 (싱글톤)public class MemberRepository { private static Map store = new HashMa..