MVC패턴의 역사
1979년 데스크톱 어플리케이션을 위해 나온 설계.
그 전에는 사람의 추상화 모델과 컴퓨터의 모델이 일치하지 않았는데 그 간극을 해결하기 위해 개발됨.JSP Model 1
이전에는 동적 웹페이지를 생성하는 언어인 JSP(Java Server Pages)를 많이 사용했는데, 이는 HTML과 JAVA가 합쳐진 형태로써 비즈니스 로직과 출력 코드가 한 페이지에 전부 삽입되어서 코딩은 쉽지만 유지보수가 어렵다는 단점이 있었음.JSP Model 2
JSP Model 1의 단점을 개선하기 위해 MVC 패턴이 적용된 JSP Model 2가 나왔고, 비즈니스 로직과 출력 로직이 구분되어 유지보수가 용이할 뿐 아니라 뷰, 로직에 대한 분업이 가능해짐.
하지만 아직도 모델과 뷰가 분리된 MVC 패턴의 모습은 아님.Cocoa MVC
우리가 알고있는 Model과 View를 분리한 지금의 MVC패턴은 애플의 라이브러리인 코코아를 이용해서 iOS를 설계하기 위해 개발하였고 코코아를 통해 세상에 발표함.
MVC의 흐름
사용자가 컨트롤러에 요청
-> 모델이 비즈니스 로직을 수행(Service, Repository)
-> 다시 컨트롤러가 데이터를 받아서 뷰에 출력
-> 사용자가 확인
Model
- 데이터와 행동을 갖는 객체
- 비즈니스 로직 수행
- 상태 변화 처리
- 상태 정보 반환
View
- 데이터를 시각화 함.
- 모델이 처리한 데이터를 받아서 사용해야 하기 때문에 데이터나 로직이 있으면 안됨.
Controller
- 컨트롤러는 사용자의 요청을 해석해서 처리
- 결과를 반환함
- 다른 컴포넌트들의 존재를 알고있는 컴포넌트이기 때문에 데이터 흐름을 제어
MVC패턴을 사용하는 이유
- 구성요소들의 재사용(ex. 웹 어플리케이션 -> 앱 어플리케이션으로 확장시)
- 확장성 증가(모델은 그대로 두고 컨트롤러와 뷰(HTML)만 커스텀하여 사용도 가능)
- 중복 코딩 제거
- 각 요소들에 집중(모델, 뷰 등 수정해야 할 부분만 따로 수정할 수 있기 때문에 유지보수가 용이)
MVC패턴만 사용하게 되면 컨트롤러에 많은 로직이 쌓이게 되고 그 흐름들을 처리하는데 중복 코드가 발생함.
그래서 현대에는 MVC패턴이 녹아있는 5가지 계층(Layer)으로 나눔
- Presentaion Layer
- Control Layer
- Busniss Logic Layer (Service, Domain)
- Persistence Layer
- Domain Model Layer
- Presentaion Layer과 Control Layer는 View와 Controller와 동일
- Service는 Control Layer와 Presentaion Layer를 연결해줌
- Domain Object는 데이터 행위를 갖는 객체
MVC 사용 규칙
- Model은 Controller와 View에 의존하지 않아야한다.
(Model 내부에 Controller와 View에 관련된 코드가 존재하지 않아야 한다.) - View는 Model에만 의존해야하고, Controller에는 의존하면 안 된다.
(View 내부에 Model의 코드만 있을 수 있고, Controller의 코드가 존재하면 안 된다.) - View가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다.
(반대로 말하면 고정 레이아웃과 같이 View가 자체적으로 가지고 있어야 하는 정보들은 Model로부터 받으면 안 된다.) - Controller는 Model과 View에 의존해도 된다.
(Controller 내부에는 Model과 View의 로직이 존재할 수 있다.) - View가 Model로 부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.
(View는 Model로부터 정제된 정보를 Controller를 통해서만 받는다.
ex. model.addAttribute("productList", productList) )
유효성 검증
필요로 하는 파라미터가 있는지 검증(@PathVariable, @RequestBody),
데이터에 대한 검증(@Valid), 로직에 대한 검증
