(Spring) MVC

더보기

JSP 모델 1 구조

웹 브라우저의 요청을 JSP가 받아 직접 처리(로직, 출력) 따라서 비즈니스 로직을 처리하기 위한 코드와 웹 브라우저에 결과를 출력하는 코드가 혼재한다.

JSP 모델 2 구조

웹 브라우저의 요청을 단일 서블릿이 받아 로직 클래스에서 로직을 처리하고, 결과를 보여줄 JSP 페이지로 포워딩. JSP는 출력만 처리. 웹 브라우저의 요청을 단일 진입점, 하나의 서블릿에서 처리한다는 점이 특징이다. 그래서 서블릿에서 웹 브라우저의 요청을 구분해서 출력을 생성할 JSP를 선택하게 된다. 모델 2 구조가 곧 MVC 패턴을 웹에 적용한 것이라고 생각하면 된다.

JSP 모델 2 구조 기반 MVC

• Model : 명확한 규칙은 없으나 보통 로직 처리 클래스, 자바빈, 서비스
• View : JSP, HTML
• Controller : 서블릿

MVC 패턴

---- 1. 요청 ---> 컨트롤러 <----- 2. 비즈니스 로직 처리 -----> 모델
사용자                      ｜ 3. 뷰 선택
<--- 4. 응답 ----   뷰

비즈니스 로직에는 포함되지 않지만, 전체 웹 어플리케이션에 일괄적으로 적용되는 기능(e.g. 사용자 인증)은 필터나 인터셉터로 서블릿(컨트롤러)에서 처리하게 된다.

항상 Interface를 만들 필요는 없다

• 어차피 구현체(클래스)가 하나밖에 없고, 이후에도 추가될 가능성이 없는 경우에는 굳이 interface 따로 작성 안하고 바로 class를 참조한다.
• interface를 쓰는건 구현체 의존성을 낮추기 위함인데, 어차피 구현체가 1개이면 interface를 쓰는 의미가 없기 때문.
• 이후 구현체를 추가로 만들며 2개 이상이 되는 경우, 그 때 interface를 정의하고 참조를 변경해도 별다른 부담이 되지 않는다.
• interface가 아닌 구현체를 참조하면 Test 시 Mock 구현체를 주입하기 더 어려워지는 것 아닌가요? ⇒ 테스트 프레임워크가 워낙 잘 되어 있어서 테스트 하는데 별다른 불편함을 느끼지 못했다. 예를 들어 Mock Bean은 @Primary 같은 애너테이션을 통해서도 주입 가능하다.
• 관습적으로 interface를 만들지 말고, “구현체가 다분화 될 수 있는 상황이라, 다형성이 필요하다” 라는 보다 근본적인 이유에 대해서 따져보는 것이 좋다.