Spring MVC, DI, IOC
MVC란?
MVC는 Model-View-Controller의 약자이며, 어플리케이션을 구성하는 요소를 역할에 따라 세 가지 모듈로 나누어 구분한 패턴이다.
1. Model(모델)
어플리케이션의 데이터이며, 모든 데이터 정보를 가공하여 가지고 있는 컴포넌트이다.
- 사용자가 이용하려는 모든 데이터를 가지고 있어야하며, View(뷰) 또는 Controller(컨트롤러)에 대해 어떠한 정보도 알 수 없어야 한다.
- 변경이 일어나면 처리 방법을 구현해야 한다.
2. View(뷰)
시각적인 UI요소를 지칭하는 용어다
- Model(모델)이 가지고 있는 데이터를 저장하면 안된다.
- Model(모델)이나 Controller(컨트롤러)에 대한 정보를 알면 안되며 단순히 표시를 해주는 역할을 가지고 있다.
- 변경이 일어나면 처리 방법을 구현해야한다.
3. Controller(컨트롤러)
Model(모델)과 View(뷰)를 연결해주는 역할을 한다.
- Model(모델) 또는 View(뷰)에 대한 정보를 알아야한다.
- Model(모델) 또는 View(뷰)의 변경을 인지하여 대처를 해야한다.
MVC 구조
1. 핸들러 조회
핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회한다.
2. 핸들러 어댑터 조회
핸들러를 실행할 수 있는 핸들러 어댑터를 조회한다.
3. 핸들러 어댑터 실행
조회한 핸들러(컨트롤러)를 인자로 핸들러 어댑터에 넘겨서 핸들러를 실행시킨다.
4. ModelAndView 반환
핸들러(컨트롤러)가 로직을 수행하고 반환하는 정보로 ModelAndView로 반환해서 반환한다.
5. viewResolver 호출
적절한 viewResolver를 찾고 해당 viewResolver를 호출한다.
RestController라면 이 과정과 이후 과정 없이 컨버터를 이용해 바로 결과값을 리턴한다.
6. View 반환
viewResolver는 뷰의 논리 이름을 물리 이름으로 바꾸고, 랜더링 역할을 담당하는 뷰 객체를 반환한다.
7. 뷰 렌더링
뷰를 통해서 뷰를 랜더링 한다.
MVC패턴 장단점
장점
- 기능 별로 코드를 분리하여, 가독성을 높이고 재사용성을 증가시킨다.
단점
- view와 model사이에 의존성이 높아서 애플리케이션이 커질수록 복잡해지고 유지보수가 어렵다
- 대규모의 프로그램에서 Controller에 다수의 Model과 View가 복잡하게 연결되어 코드 분석과 테스트가 어려워 질 수 있다.
DI란?
DI(Dependency Injection)는 스프링 프레임워크에서 지원하는 IoC의 형태이다.
클래스 사이의 의존관계를 빈 설정 정보를 바탕으로 컨테이너가 자동으로 연결해주는 것.
- 장점
- 스프링 자체에서 설정을 통해 연관 관계를 맺어줌으로써 객체간 결합도를 낮춰준다.
- 클래스의 재사용성을 높이고, 유지보수가 편리해진다.
- 단점
- 의존성 주입을 위한 선행 작업이 필요해 간단한 프로그램에서는 번거롭다.
- 코드 추적이 어렵다
주입 방식
- Setter 주입
- 대부분 의존 관계 주입은 한번 일어나면 종료시점까지 변경할 일이 거의 없다
- Setter를 통해 주입하게 되면 변경될 위험이 존재
- Setter를 public으로 열어야함
- 필드 주입
- 외부에서 변경이 불가능해 테스트하기 어렵다
- 생성자 주입
- 제일 권장하는 방법
- 생성자 호출 시점에서 딱 1번만 호출되는 것을 보장
- final 키워드를 통해 불변하게 설계 가능
- 의존성 주입이 누락되는 것을 방지할 수 있음 (컴파일 오류로 알려줌)
IOC란?
IOC(Inverse of Control) 제어의 역전으로 객체의 생성부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀐 것을 의미한다.
개발자는 프레임워크에 필요한 부품을 개발하고 조립하는 방식으로 개발을 하고 최종 호출은 개발자가 아니고 프레임워크의 내부에서 결정된 대로 이뤄지게 되는데 이런 현상을 제어의 역전이라고 한다.