발자국남기기

스프링이 제공하는 컨트롤러는 애노테이션 기반으로 동작하므로 매우 유연하고 실용적이다. @RequestMapping 스프링은 애노테이션을 활용한 매우 유연하고 실용적인 컨트롤러를 만들었는데 이것이 바로 @RequestMapping을 사용하는 컨트롤러이다. 실무에서도 거의 이 방식의 컨트롤러를 사용 @controller 스프링이 자동으로 스프링 빈으로 등록(내부에 @Component 애노테이션이 있어 컴포넌트 스캔의 대상) 스프링 MVC에서 애노테이션 기반 컨트롤러로 인식 @RequestMapping 요청 정보를 매핑 해당 URL이 호출되면 이 메서드가 호출된다. 메서드의 이름은 임의로 작명 ModelAndView 모델과 뷰 정보를 담아서 반환 application.properties에 prefix와 suf..

위와 같이 ModelAndView에 논리주소를 담아 반환하여 해당 url로 접속해보면 위와 같은 404페이지가 뜨는데 이는 현재 ViewResolver가 없기 때문에 매칭되는 뷰를 찾지못했다는 오류이다. 뷰 리졸버 : InternalResourceViewResolver 스프링부트는 InternalResourceViewResolver라는 뷰 리졸버를 자동으로 등록하는데, 이때 application.properties에 등록한 spring.mvc.view.prefix (접두사), spring.mvc.view.suffix(접미사)를 사용하여 등록한다. 위와 같이 application.properties에 등록해두면 우리가 ModelAndView에 넣은 논리주소인 new-form과 더해져서 /WEB-INF/vi..

현재는 @Controller라는 애노테이션을 사용하여 컨트롤러를 사용하지만 과거에는 아래와 같은 딱딱한 방식의 컨트롤러를 제공했었다.(지금은 사용 X) @Component를 통해 해당 컨트롤러는 /springmvc/old-controller라는 이름의 스프링 빈으로 등록 빈의 이름으로 URL을 매핑 http://localhost:8080/springmvc/old-controller 주소로 접속하면 콘솔창에 출력이 찍힐 것이다. HandlerMapping 핸들러 매핑에서 해당 컨트롤러를 찾을 수 있어야함. ex)스프링 빈의 이름으로 핸들러를 찾을 수 있는 핸들러 매핑 HandlerAdapter 핸들러 매핑을 통해 찾은 핸들러를 실행할 수 있는 핸들러 어댑터가 필요 ex) Controller 인터페이스를 실..

앞서 직접 만들어보았던 MVC 프레임워크와 구조가 굉장히 유사하다. FrontController ==> DispatcherServlet handlerMappingMap ==> HandlerMapping MyHandlerAdapter ==> HandlerAdapter ModelView ==> ModelAndView viewResolver ==> ViewResolver MyView ==> View DispatcherServlet 구조 살펴보기 스프링 MVC도 프론트 컨트롤러 패턴으로 구현되어 있다. 스프링 MVC의 프론트 컨트롤러가 바로 DispatcherServlet 이것이 스프링 MVC의 핵심이다. 상속관계를 다이어그램으로 살펴보면 DispatcherServlet도 결국 HttpServlet을 상속받아 ..

현재는 어떤 컨트롤러 interface를 사용할 것인지 지정되어 있기 때문에 컨트롤러에 따라 다른 interface를 사용하는 것이 불가능하다. 만약 각각의 컨트롤러에 따라 다른 interface를 사용하고 싶다면 이때 사용하는 것이 어댑터이다. 어댑터 패턴을 사용하여 프론트 컨트롤러가 다양한 방식의 컨트롤러 interface를 처리하도록 해보자. 핸들러 어댑터 : 중간에서 다양한 종류의 컨트롤러를 호출할 수 있는 어댑터 역할 핸들러 : 컨트롤러에 국한된 개념이 아니라 어떤 것이든 해당하는 종류의 어댑터만 있다면 다 처리 가능 어댑터 Interface supports : 어댑터 목록을 조회하여 해당 컨트롤러를 처리할 수 있는지 판단하는 메서드 True / False 값 반환 handle : 실제 컨트롤러..

앞서 만든 컨트롤러는 서블릿 종속성을 제거하고 뷰 경로의 중복을 제거하여 컨트롤러를 설계했다. 하지만 컨트롤러 인터페이스를 구현해야하는 입장에서 보면 항상 ModelView객체를 생성하여 반환해야하는 부분은 번거롭다. 이를 실용성을 가지도록 변경해보자 새로운 구조 컨트롤러가 ModelView를 반환하는 것이 아니라 ViewName만 반환한다. 컨트롤러 Interface 회원 Form 컨트롤러 viewName만 반환해준다. 회원 Save 컨트롤러 모델을 parameter로 제공받기 때문에 새로운 회원객체를 만들어 model에 put해주면 된다. 역시 마찬가지로 viewName만 반환 회원 List 컨트롤러 모델을 처리하는 과정은 FrontController에서, 각 구현 컨트롤러는 모델에 put만 해주고 ..

서블릿 종속성 제거 요청 파라미터 정보는 Map으로 넘기도록 하면 현재 구조에서는 Controller가 서블릿 기술을 몰라도 동작할 수 있다. request 객체를 Model로 사용하는 대신 별도의 Model 객체를 만들어서 반환하면 된다. 현재는 request객체 내부 저장소를 Model처럼 사용하고 있음. Controller가 서블릿 기능을 전혀 사용하지 않도록 변경해보자 뷰 이름 중복 제거 Controller 에서 지정하는 뷰 이름에 중복이 있음. Controller는 뷰의 논리 이름을 반환하고, Front Controller에서 이를 실제 위치로 처리하도록 단순화 Front Controller에서 처리하도록 만들면, 뷰의 폴더 위치가 변해도 Front Controller만 변경하면 되므로 훨씬 코..

현재 컨트롤러에서 뷰로 이동하는 부분에 중복이 존재한다. 이 부분을 분리하여 별도로 뷰를 처리하는 객체를 만들 것이다. 렌더링을 통해 view를 호출하는 MyView 클래스 새로운 컨트롤러 인터페이스 반환을 MyView로 반환 위와 같이 각 컨트롤러들을 구현하는데 새로운 MyView객체에 viewPath을 넣어 반환해주면 MyView에서 이를 처리해주는 것이다. 다른 컨트롤러도 위와 마찬가지로 작성 중복을 제거할 수 있다. FrontController 내부 구조만 리팩토링한 것이기 때문에 기능은 전과 똑같이 동작함

프론트 컨트롤러 패턴을 사용하지 않으면 공통 부분이 계속 중복되어 호출된다 프론트 컨트롤러를 도입하게 되면 공통부분을 컨트롤러 앞에서 처리하고 각 컨트롤러로 들어가게 되는 것이다 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출 공통 처리 기능 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨 스프링 웹 MVC의 핵심이 바로 FrontController 스프링 웹 MVC의 DispatcherServlet이 FrontController 패턴으로 구현되어 있음 FrontController 도입 컨트롤러 인터페이스를 만들고, 각 컨트롤러들이 이를 구현하도록 만들겠다. 컨트롤러 인터페이스 서블릿과 동일한 구조를 가지고 있음. 이를 ..

하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을 하게되고, 결과적으로 유지보수가 어려워진다. 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 수정해야하고, UI를 변경할 일이 있어도 비즈니스 로직이 함께 있는 파일을 수정해야한다. 코드의 양이 수백 수천줄이라면 이 작업은 매우 어려워지고 복잡해진다. 변경의 라이프 사이클 둘 사이의 변경 라이프 사이클이 다르다는 점이다. UI를 일부 수정하는 일과 비즈니스 로직을 수정하는 일은 각각 다르게 발생할 가능성이 매우 높고 대부분 서로에게 영향을 주지 않는다. 이렇게 변경의 Life Cycle이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기에 좋지 않다. 기능 특화 JSP 같은 뷰 템플릿은 화..