MVC(Model–View–Controller)

DispacherServlet이란?

사용자가 HTTP를 보내면 대기중인 DispacherServlet이 이 요청에 대해 HandlerMapping한테 이 요청을 어느 컨트롤러로 보내야 하냐고 물어보고 HandlerMapping이 “이 쪽입니다”하면 “OK”하고 보냄

DispacherServelt은 모든 요청을 모아 두는 곳이 아니라 한 곳에서 받는 거임

한 곳에서 받는다는 의미가 클라이언트에게 받고 돌려주고 할 때 모두 DispacherServlet을 거쳐서 한 곳에서 받는다는 표현인 거임

 

…이게 MVC랑 뭔상관이길래?

클라이언트가 서버와 소통할 때

1. 클라이언트가 http 요청을 보내면 DispacherServlet이 받음
2. HandlerMapping한테 지시를 내림(어느 Controller에게 보내야 하는지 알아내)
3. DispacherServlet이 해당 Controller에게 요청을 보내면 Controller가 JSON형태의 자바 객체로 변환하여 Model에 보냄 (비즈니스 로직-서비스 / Model)
4. Model은 DB에 접근하여 데이터를 읽거나 쓰거나 해서 다시 Controller에게 보내주면 Controller가 DispacherSerlvet에 응답 데이터(결과)를 반환함
5. DispacherServlet이 클라이언트에게 View 형태로 보내면 화면에 렌더링이 됨

 

그래서 MVC가 뭔데?

Model-View-Controller의 약자로, 웹 애플리케이션의 역할을 기능별로 분리한 아키텍처 패턴임

Model은 비즈니스 로직

View는 화면 또는 응답

Controller는 사용자의 요청을 받아 Model고 View를 연결해 주는 중간 다리

 

그래서 핵심이 뭐임 ⇒ 관심사를 분리했다는 점

화면, 로직, 제어를 나눠서 각 부분을 독립적으로 개발하고 수정할 수 있게 함

 

왜 독립적으로 개발해야만 하는 건데?

하나를 고칠 때 나머지가 영향을 받지 않게 하기 위함

유지 보수성, 확장성, 재사용성이 해당되겠지

예를 들어 화면을 바꿔도 비즈니스 로직을 건드리지 않아도 되고

기능을 추가할 때 Controller만 수정하면 되기 때문

그래서 MVC패턴은 화면 로직 제어를 분리하여

한 부분을 수정하거나 확장할 때 다른 부분이 영향을 받지 않게 하기 위한 아키텍처 패턴임

controller는 단순히 중간자 역할만 할까?

사용자의 요청을 받아 어떤 비즈니스 로직 -모델 를 호출할지 결정함

그 결과를 View에게 전달해주는 역할도 함

입출력 제어가 가능하다

Model이 데이터인가?

비즈니스 로직을 수행하는 영역이지 데이터는 아님

결제 승인 포인트 적립 등이 모델에 포함됨

스프링에서는 Service, Repository, entity가 Model에 해당됨

MVC가 되게 중요해 보이는데 안쓰면?

화면, 로직, 데이터가 섞여 있어서 한 부분을 수정하면 다른 부분이 쉽게 깨짐

View안에 SQL이 섞여있으면 디자인 바꿔도 로직이 오류를 일으킬 수 있음

디자인이 뭐임 화면임? ㅇㅇ 화면임

그래서 DispacerServlet이랑 뭔 관계인데

모든 HTTP 요청을 한 곳에서 처리하는데 이게 DispacherServlet

1. 요청 받았을 때 : HandlerMapping이 어느 Controller로 처리할지를 결정하고
2. 반환할 때 : 결과를 ViewResolver를 통해 View로 전달한 뒤 응답함

MVC 패턴 단점이 있을까?

구조가 명확해서 난 좋기만 한데 단점이 있긴한가

계층이 많아지면 하나 변경 할 때 Controller, Service, Repository를 변경해야 할 수도 있나? ㅇㅇ 있음

이걸 오버엔지니어링이라고 하나봄

계층 간 결합도가 높아진다는데 그럼 MVC는 OCP가 아닌 건가?

느슨한 결합 형태임

DispacherServlet은 controller인터페이스 형태만 알고있고 구현체는 모름

HandlerMapping도 URL과 controller 매핑정보만 알고 있음

viewResolver도 View이름만 받아서 View객체를 리턴할 뿐 Controller를 모름

즉, 각자 추상화(인터페이스)만 알고 구현체는 모름

Spring MVC가 OCP를 유지하는 방식

의존성 역전(DIP)과 추상화(인터페이스)