MVC 패턴이 무엇인가요?
MVC 는 Model, View, Controller의 약자 입니다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴입니다.
사용자가 Controller를 조작하면 Controller는 Model을 통해 데이터를 가져오고 그 데이터를 바탕으로 View를 통해 시각적 표현을 제어하여 사용자에게 전달하게 됩니다.
모델 (Model)
Model은 어플리케이션이 “무엇”을 할 것인지를 정의 합니다. 내부 비지니스 로직을 처리하기 위한 역할을 할 것입니다.
모델의 규칙
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 함
- 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야 함
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 함
뷰 (View)
View는 화면에 “무엇” 인가를 “보여주기 위한 역할”을 합니다. 컨트롤러 하위에 종속되어, 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 것들을 보여줄 것입니다.
뷰의 규칙
- 모델이 가지고 있는 정보를 따로 저장해서는 안됨
- 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야 함
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 함
컨트롤러 (Controller)
Controller는 모델이 “어떻게” 처리할 지를 알려주는 역할을 할 것이고, 모바일에서는 화면의 로직처리 부분입니다. 화면에서 사용자의 요청을 받아서 처리되는 부분을 구현되게 되며, 요청 내용을 분석해서 Model과 View에 업데이트 요청을 하게 됩니다.
컨트롤러의 규칙
- 모델이냐 뷰에 대해서 알고 있어야 함
- 모델이나 뷰의 변경을 모니터링해야 함
요약)
Model — 백그라운드에서 동작하는 비즈니스 로직(데이터) 처리
View — 정보를 화면으로 보여주는 역할.
Controller — 사용자의 입력 처리와 흐름 제어 담당. 화면과 Model과 View를 연결시켜주는 역할
꼬리질문) 디자인 패턴이란 무엇인가요?
소프트웨어의 개발 방법을 공식화 한 것이다. 소수의 뛰어난 엔지니어가 해결한 문제를 다수의 엔지니어들이 처리 할 수 있도록 한 규칙이면서, 구현자들 간의 커뮤니케이션의 효율성을 높이는 기법이다.
꼬리질문) MVC 패턴의 등장 이유에 대해 설명해주세요.
등장이유는 간단히 생산성이 좋기 때문이다.
생산성은 크게 4가지로
- 구성요소들의 재사용 (ex.콘솔용 어플을 웹으로 확장 할때 모델은 그대로 재사용 가능)
- 확장성 증가
- 중복 코딩 제거
- 각 요소들에 집중가능
MVC 이전의 JSP Model1 에서는 하나의 클래스에 로직 + 출력이 같이 존재 했고
유지보수가 어려운 단점이 있었다.
MVC를 적용하며 Model(로직)과 View(출력)가 분리 되었고 협업도 용이해 지게 되었다.
꼬리질문) MVC패턴의 모델1과 모델2 차이점을 설명해주세요
- Model 1 : 비즈니스 로직 영역(Controller)에 프레젠테이션 영역(View)을 같이 구현하는 방식이다.
사용자의 요청을 JSP가 전부 다 처리한다. 웹 브라우저 사용자의 요청을 받은 JSP는 자바빈이나 서비스 클래스를 사용하여 웹 브라우저가 요청한 작업을 처리하고 그 결과를 출력해준다. - Model 2 : 비즈니스 로직 영역과 프레젠테이션 영역이 분리되어 있는 구현 방식이다.웹 브라우저 사용자의 요청을 Servlet이 받는다. Servlet은 요청을 View로 보여줄 것인지, Model로 보내줄 것인지 정하여 전송한다. 여기서 View 페이지는 사용자에게 보여주는 역할만 담당하고 실질적인 기능의 부분은 Model에서 담당한다.
- 장점
Model 1 : 모델 1 방식을 채택하면 빠르고 쉽게 개발할 수 있다는 장점이 있다.
Model 2 : 모델2 방식은 View와 Controller를 분리하는 방식이다. 따라서 디자이너와 개발자의 분업이 가능하며 유지보수에 유리하다
- 단점
Model 1 : JSP파일 자체가 너무 비대해지고, Controller와 View가 혼재하므로 향후 유지보수에 어려움을 겪을 수 있다.
Model 2 : 설계에서 어려움을 겪을 수 있고, 개발 난이도가 높다는 단점이 있다.
MVC 패턴을 사용할 때 지켜야 할 점이 무엇인가요?
- Model은 Controller와 View에 의존해서는 안된다.
- Model이 Controller, View의 책임을 가지면 안 된다는 것이다. 각 레이어에서 담당하는 책임이라는 것이 존재한다.
- 오로지 데이터에 대한 순수 로직 만 존재하는 것이 바람직하다.
2. View는 model에만 의존한다.
여기서의 의존은 코드의 의존이 아니라 순수 도메인 데이터에 대한 의존이다.
- view에서 사용되는 값은 Model에서 전달된 값이어야 한다. 컨틀로가 Model에 대한 값을 View로 넘겨준다.
3. View는 Model로부터 사용자마다 다르게 변경되는 데이터만 받아야 한다.
- 용자마다 다른 생애주기를 가진 data만을 Model은 받아야 한다.
[ 공통된 정보에 대해서는 자체적으로 View가 소유해야 한다. ] - 공통으로 처리되는 부분에 대해서는 View자체에서 처리되어야 한다.
4. Controller는 Model과 View에 의존해야 한다.
5. View가 Model로부터 데이터를 받을 때는 Controller에서 받아야 한다,
- Controller는 요청에 맞는 서비스를 호출하고 그에 로직이 처리된 Model의 결과를 View로 전달해야 한다.
MVC 패턴을 사용하면 어떤 장점이 있나요?
MVC 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시작적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있게 됩니다.
- 비즈니스 로직과 UI로직을 분리하여 유지보수를 독립적으로 수행가능
- Model과 View가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리함
- 중복 코딩의 문제점 제거
MVC 패턴을 사용하면 단점은 무엇인가요?
뷰와 모델이 서로 의존성을 띄게 됩니다. 화면에 복잡한 화면과 데이터의 구성 필요한 구성이라면, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 생길 수 있습니다.
MVC에서 View는 Controller에 연결되어 화면을 구성하는 단위요소이므로 다수의 View들을 가질 수 있습니다. 그리고 Model은 Controller를 통해서 View와 연결되어지지만, 이렇게 Controller를 통해서 하나의 View에 연결될 수 있는 Model도 여러개가 될 수 있습니다.
- 비대한 컨트롤러
서비스가 커질수록 컨트롤러의 코드가 증가할 수 밖에없음 - 컨트롤러의 중복 로직
- DB 접근성
DB에서 MVC중 어느 객체로 접근을 해야하는지 모호함
MVC 패턴의 한계는 무엇인가요?
Model과 View는 서로의 정보를 갖고 있지 않는 독립적인 상태라고 하지만 Model과 View사이에는 Controller를 통해 소통을 이루기에 의존성이 완전히 분리될 수 없습니다. 그래서 복잡한 대규모 프로그램의 경우 다수의 View와 Model이 Controller를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생하기도 합니다. 이러한 현상을 Massive-View-Controller현상이라고 하며 이를 보완하기 위해 MVP, MVVM, Flux, Redux등의 다양한 패턴들이 생겨났습니다.
MVC 패턴의 대안이 있다면 알려주세요.
MVP, MVVM, Flux, Redux등
- MVP 패턴
MVP 패턴은 MVC와 유사한 디자인 패턴입니다. 기존 Controller의 역할을 Presenter가 합니다. MVP 패턴에서 Presenter는 Model을 조작할 뿐만 아니라 View를 업데이트합니다. Presenter와 View는 서로 완전히 분리되어 인터페이스를 통해 통신합니다. 이 방식은 MVC보다 단위테스트가 훨씬 쉬워집니다.
장점 : MVP패턴은 인터페이스를 통해 통신하기 때문에 MVC의 단점으로 지적되었던 View와 Model사이의 의존성이 없습니다.
단점: View와 Presenter사이의 의존성이 높고, 앱이 커질수록 이 의존성은 더 강해집니다.
- MVVM 패턴
MVVM 패턴은 양방향 데이터 바인딩을 지원합니다. 이에 따라 뷰 모델 안에 있는 데이터의 변화를 View에 전파합니다. 일반적으로 옵저버 패턴을 활용하여 View Model의 변경사항을 Model에게 알립니다.
언뜻 보기에는 MVP와 비슷한 부분이 많으나 MVP는 View와 Presenter 사이의 의존관계가 1:1로 형성되어있다면, MVVM은 View와 ViewModel사이의 관계가 1대n으로 되어있습니다. 또한 데이터 바인딩을 이용한다면 View와 ViewModel 사이의 의존성을 없앨 수 있습니다.
- Flux 패턴
Flux는 사용자 입력을 기반으로 Action을 만들고 Action을 Dispatcher에 전달하여 Store(Model)의 데이터를 변경한 뒤 View에 반영하는 단방향의 흐름으로 애플리케이션을 만드는 아키텍처입니다.
- Redux 패턴
리덕스는 일종의 상태 관리 라이브러리이다. 리액트에서 우리는 사이트의 여러 부분을 조각내서 컴포넌트로 만들고 각각의 컴포넌트에는 하위 컴포넌트가 존재한다. 그리고 이런 컴포넌트에는 state라는 상태가 존재하며 상위 컴포넌트에서 하위 컴포넌트로 props로 전달하여 관리된다. 그런데 리덕스를 사용한다면 컴포넌트끼리 상태를 공유할 때 여러 컴포넌트를 거치지 않고 손쉽게 전달할 수 있게 된다.
