[아키텍처 패턴] MVC 패턴이란?

MVC (Model-View-Controller) Pattern 은 자주 사용되는 디자인 패턴이다.,
one of the most frequently used design patterns

 이 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다. MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.

 

구성요소

모델-뷰-컨트롤러는 응용 프로그램을 세 가지의 구성요소로 나눈다. 각각의 구성요소들 사이에는 다음과 같은 관계가 있다.

컨트롤러는 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있다. (예 : 워드프로세서에서 문서를 편집하는 것) 또 컨트롤러가 관련된 뷰에 명령을 보냄으로써 모델의 표시 방법을 바꿀 수 있다. (문서를 스크롤 하는 것)

MVC의 뷰는 여러 개의 컨트롤러(Controller)를 가지고 있다. 사용자는 컨트롤러를 사용하여 모델의 상태를 바꾼다. 컨트롤러는 모델의 mutator 함수를 호출하여 상태를 바꾼다. 이때 모델의 상태가 바뀌면 모델은 등록된 뷰에 자신의 상태가 바뀌었다는 것을 알리고 뷰는 거기에 맞게 사용자에게 모델의 상태를 보여 준다.

모델은 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보한다. 이와 같은 통보를 통해서 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가 제거 수정할 수 있다. 어떤 MVC 구현에서는 통보 대신 뷰나 컨트롤러가 직접 모델의 상태를 읽어 오기도 한다.

모델(model)이란 어떠한 동작을 수행하는 코드를 말한다. 표시 형식에 의존하지 않는다. 다시 말해, 사용자에게 어떻게 보일지에 대해 신경쓰지 않아도 된다. 모델은 순수하게 public 함수로만 이루어진다. 몇몇 함수들은 사용자의 질의(query)에 대해 상태 정보를 제공하고 나머지 함수들은 상태를 수정한다.

뷰는 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어 온다.

MVC에서 모델은 여러 개의 뷰(view)를 가질 수 있다. 뷰는 모델에게 질의를 하여 모델로 부터 값을 가져와 사용자에게 보여준다.

 

원리

자바언어에서 모델은 java.util.Observable을 상속(extends)받아 만들 수 있다. 모델에는 현재의 상태 정보를 변경하거나 다른 클래스에게 알릴 수 있는 함수가 있어야 한다. 모델의 상태를 변경하는 함수(mutator)는 setChanged()와 notifyObservers()를 호출하여야 한다. notifyObservers는 모델에 등록된 모든 뷰에게 업데이트 메시지를 보내게 된다. 뷰는 java.util.Observer를 implement하여 만들면 update method를 구현할 수 있다. update함수의 두 번째 매개변수는 Object 모델에서 넘어온 추가정보를 받는 데에 사용된다.

interface Observer{	
	void update(Observable t, Object o);
}

뷰는 반드시 모델에게 질의하여 업데이트하는 부분이 구현되어야 한다. 모델은 addObserver라는 함수를 이용하여 뷰를 자신에게 등록시킨다. 모델은 자신에게 등록된 모든 뷰를 기억하고 있다가 자신의 상태가 바뀌게 되면 등록된 모든 뷰에 notify 함수를 호출하여 뷰를 update시킨다. 모델은 뷰를 여러 개 가질 수 있다. MVC에서는 이것을 허용하고 있다. 또한 뷰도 여러개의 모델에 등록될 수 있다.

 

출처 : 위키백과

---

- MVC 모델은 디자인 패턴 중 하나이다.

디자인 패턴이란?
프로그램이나 어떤 특정한 것을 개발하는 중에 발생했던 문제점들을 정리해서 상황에 따라 간편하게 적용해서 쓸 수 있는 것을 정리하여 특정한 "규약"을 통해 쉽게 쓸 수 있는 형태로 만든 것을 말한다.
프로그램이나 어플리케이션을 만든다고 할 때 유지보수하고 다른 사람과 공유를 하며 만들어야 할 때 더 쉽고 깔끔하게 만들 수 있는 방법을 고안해야 한다. 만약 이러한 방법을 명확하게 하지 않는다면 우리는 클래스 함수를 일일이 다 만들어야 할 것이다.

라이브러리나 프레임워크가 그에 따른 예이다. 예를 들어 그냥 jQuery를 이용한다면 $('#lucid')로 DOM을 선택할 수 있는 것을 그냥 순수Javascript를 사용한다면 document.getElementsByid('lucid')로 길게 써가며 찾아야 한다. 예를 들어 어떠한 data를 만들고 이 data를 수정할 로직을 짠다. 그리고 그 data를 보여주는 부분을 만들 때 이거 하나하나가 로직이 분리가 안되있고 한꺼번에 정의가 되어있다면? 나중에 유지보수하기가 힘들겁니다. 그걸 "돕기" 위해 디자인패턴이라는게 나오는 것이며 이렇듯 "좀 더 쉽고 편리하게" 사용할 수 있게 만든 특정한 방법들을 디자인 패턴이라고 한다. 그 디자인 패턴이라는 것은 스트래티지 패턴, 옵저버 패턴 등등 정말 여러가지가 있고 그 중에 하나가 바로 MVC패턴입니다.

 

MVC란?

MVC 는 Model, View, Controller의 약자 입니다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴입니다.

출처 : 오픈듀토리얼스

위의 그림처럼 사용자가 controller를 조작하면 controller는 model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 됩니다. 저건 하나의 로직을 설명하기 위해 만든 그림이고 사실 MVC 패턴의 구조는

출처:XESCHOOL

이 그림이 더 어울릴 것입니다. Controller가 view에도 영향을 미치는(화살표를 보자) 부분이 있어야 합니다.

위의 그림을 보면서 다시 MVC 패턴이 뭔지 감을 잡도록 해봅시다. 모델은 컨트롤러에 컨트롤러는 뷰에 뷰는 다시 유저 유저는 다시 컨트롤러를 향해서 갑니다.

 

- 모델, Model

애플리케이션의 정보, 데이타를 나타냅니다. 데이타베이스, 처음의 정의하는 상수, 초기화값, 변수 등을 뜻합니다. 또한 이러한 DATA, 정보들의 가공을 책임지는 컴포넌트를 말합니다.

이 모델은 다음과 같은 규칙을 가지고 있습니다.

1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.

즉, 화면안의 네모박스에 글자가 표현된다면, 네모박스의 화면 위치 정보, 네모박스의 크기정보, 글자내용, 글자의 위치, 글자의 포맷 정보 등을 가지고 있어야 한다는 것입니다.

2. 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.

데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안 된다는 말입니다.

3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.

모델의 속성 중 텍스트 정보가 변경이 된다면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법을 구현해야 합니다. 또한 모델은 재사용가능해야 하며 다른 인터페이스에서도 변하지 않아야 합니다.

 

뷰, View

input 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타냅니다. 다시 말해 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당합니다. 데이타를 기반으로 사용자들이 볼 수 있는 화면입니다.

뷰에서는 다음과 같은 규칙들이 있습니다.

1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.

화면에 글자를 표시 하기 위해, 모델이 가지고 있는 정보를 전달받게 될텐데, 그 정보를 유지하기 위해서 임의의 뷰 내뷰에 저장하면 안됩니다. 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고 그 화면을 그릴 때 필요한 정보들은 저장하지 않아야 합니다.

2. 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.

모델과 같은 자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안됩니다. 그냥 뷰는 데이터를 받으면 화면에 표시해주는 역할만 가진다고 보면 됩니다.

3. 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.

모델과 같이 변경이 일어났을 때 이른 누군가에게 변경을 알려줘야 하는 방법을 구현해야 합니다. 뷰에서는 화면에서 사용자가 화면에 표시된 내용을 변경하게 되면 이를 모델에게 전달해서 모델을 변경해야 할 것이다. 그 작업을 하기 위해 변경 통지를 구현합니다.

그리고 재사용가능하게끔 설계를 해야 하며 다른 정보들을 표현할 때 쉽게 설계를 해야 합니다.

 

- 컨트롤러,Controller

데이터와 사용자인터페이스 요소들을 잇는 다리역할을 합니다. 즉, 사용자가 데이터를 클릭하고, 수정하는 것에 대한 "이벤트"들을 처리하는 부분을 뜻합니다. 컨트롤러 또한 다음과 같은 규칙을 이해해야 합니다.

1. 모델이나 뷰에 대해서 알고 있어야 한다.

모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 합니다.

2. 모델이나 뷰의 변경을 모니터링 해야 한다.

모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 합니다.
또한, 애플리케이션의 메인 로직은 컨트롤러가 담당하게 됩니다.

 

- 왜 MVC패턴을 사용해야 할까.

사용자가 보는 페이지, 데이터처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤, 이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할 수 있게 됩니다. 공장에서도 하나의 역할들만 담당을 해서 처리를 해서 효율적이게 됩니다. 여기서도 마찬가지입니다.

서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발을 하고 그렇게 애플리케이션을 만든다면, 유지보수성, 애플리케이션의 확장성, 그리고 유연성이 증가하고, 중복코딩이라는 문제점 또한 사라지게 되는 것입니다. 그러기 위한 MVC패턴입니다.

*유연성 : 여기서 유연성이라는 것은 클라이언트의 새로운 요구사항에 대해 최소한의 비용으로 보다 유연하게 대처할 수 있는 것을 말합니다.
*비즈니스로직: 프로그램의 논리구조

 

- MVC패턴의 예

그렇다면 MVC패턴을 사용하는 프레임워크나 라이브러리는 뭐가 있을까요?
바로 다음과 같습니다!

react는 mvc 패턴만을 사용하다가 flux 패턴도 씁니다.(redux)

react는 mvc 프레임워크는 아니고 View만 신경쓰는 라이브러리입니다. 다른 웹프레임워크와는 달리 ajax, 데이터 모델링, 라우팅 같은 것이 없습니다. 그저 뷰만 신경쓰지요.

리액트는 단방향 데이터 흐름으로 데이터 변경에 관한 DOM객체만 변경해주는 체계, 데이타가 변경되면 양방향 데이터 바인딩처럼 모델 변경 > 뷰변경이 아니라 특정함수를 실행시킴으로써 DOM객체를 갱신합니다.

 

- MVC패턴의 의의

MVC패턴은 결국 "어떻게 나눌 것인가"에 대한 해답 중 하나입니다. 어떤 특정한 역할들에 대해 역할분담을 할 때 가이드라인을 제시하는 방법 중 하나가 바로 MVC패턴이라는 것입니다.

그리고 이 패턴을 사용한 라이브러리나 프레임워크로 프로그래밍을 한다면 정말 쉽고 그리고 재밌는 경험을 느낄 수 있으며 아름다운 코드가 탄생하게 됩니다. 물론 우리는 그러한 라이브러리나 프레임워크를 만들 수 있는 실력또한 길러야 하지만요.

 

출처 : m.blog.naver.com/jhc9639/220967034588

 

---

- MVC패턴이란? 

Model , View , Controller 의 합성어로 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴입니다.

Model : 백그라운드에서 동작하는 로직을 처리합니다.
View : 사용자가 보게 될 결과 화면을 출력합니다.
Controller : 사용자의 입력처리와 흐름 제어를 담당합니다.

MVC패턴에는 모델1방식과 모델2방식이 있는데 특히 모델 2 구조 기반의 MVC패턴 구현은 JSP 개발자라면 무조건 알고 있어야 할 개발 방식입니다. JSP 웹사이트 구조는 크게 모델1 방식과 모델2 방식으로 나뉩니다. 간단하게 분류하자면 JSP에서 출력과 로직을 전부 처리하느냐(모델1) JSP에서 출력만 처리하느냐(모델2)로 분류할 수 있습니다.

- Model1방식 

모델1 구조는 사용자의 요청을 JSP가 전부 다 처리합니다. 웹브라우저 사용자의 요청을 받은 JSP는 자바빈이나 서비스 클래스를 사용하여 웹브라우저가 요청한 작업을 처리하고 그 결과를 출력해줍니다.

- Model2방식

모델 2 구조는 모델 1구조와 달리 웹브라우저 사용자의 요청을 서블릿이 받습니다. 서블릿은 웹브라우저의 요청을 받아 View로 보여줄것인지 Model로 보내줄것인지 정하여 전송해줍니다. 여기서 View페이지는 사용자에게 보여주는 역할만 담당하고 실질적인 기능의 부분은 Model에서 담당합니다. 모델2 방식의 경우 실질적으로 보여지는 HTML과 JAVA 소스를 분리 해놓았기 때문에 모델1방식에 비해 개발을 확장시키기도 쉽고 유지보수하기도 쉽습니다. (코딩을 좀 더 깔끔하게 할 수 있습니다.)

MVC 패턴이라면 웹 개발자라면 반드시 알아야 하는 패턴입니다. MVC패턴은 스윙과 같은 컴포넌트뿐만이 아니라 웹어플리케이션 개발 영역에서도 보편적으로 사용하고 있습니다. 다음 포스팅에서는 MVC2 패턴으로 구현하는 회원가입과 게시판의 예제를 통해 MVC2패턴이 어떻게 돌아가는지 공부해보도록 하겠습니다.

 

출처 : coding-factory.tistory.com/

---

👩‍💻 MVC 패턴이란?

MVC - Model, View, Controller의 합성어로 소프트웨어 공학에서 사용되는 소프트웨어 *디자인 패턴이다.

*디자인 패턴이란?
: 건축으로치면 공법에 해당하는 것으로, 소프트웨어의 개발 방법을 공식화 한 것이다. 소수의 뛰어난 엔지니어가 해결한 문제를 다수의 엔지니어들이 처리 할 수 있도록 한 규칙이면서, 구현자들 간의 커뮤니케이션의 효율성을 높이는 기법이다. 
<출처-위키피디아>

 

• Model : 백그라운드에서 동작하는 로직을 처리한다. (데이터를 가진 객체, 파라미터로 주로 쓰인다.)DB의 테이블과 대응하는 경우가 많다.)

• View : 사용자가 보게 될 결과 화면을 출력한다. (html/css/javascript를 모아둔 컨테이너)

• Controller : 사용자의 입력처리와 흐름 제어를 담당한다. (사용자가 접근한 URL에 따라서 사용자의 요청사항을 파악한 후, 그 요청에 맞는 데이터를 Model에 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려준다.)
  

MVC패턴에는 Model 1 방식과 Model 2 방식이 있는데 특히 Model 2 구조 기반의 MVC 패턴 구현은 JSP 개발자라면 무조건 알고 있어야할 개발 방식이라고 한다.

 

모델 1, 모델 2의 간단 정의

• Model 1 : 비즈니스 로직 영역(Controller)에 프레젠테이션 영역(View)을 같이 구현하는 방식이다.
  사용자의 요청을 JSP가 전부 다 처리한다. 웹 브라우저 사용자의 요청을 받은 JSP는 자바빈이나 서비스 클래스를 사용하여 웹 브라우저가 요청한 작업을 처리하고 그 결과를 출력해준다.

Model 2 : 비즈니스 로직 영역과 프레젠테이션 영역이 분리되어 있는 구현 방식이다.웹 브라우저 사용자의 요청을 Servlet이 받는다. Servlet은 요청을 View로 보여줄 것인지, Model로 보내줄 것인지 정하여 전송한다.  여기서 View 페이지는 사용자에게 보여주는 역할만 담당하고 실질적인 기능의 부분은 Model에서 담당한다. 

 

모델 1, 모델 2의 장점과 단점

• 장점

  • Model 1 : 모델 1 방식을 채택하면 빠르고 쉽게 개발할 수 있다는 장점이 있다. 

  • Model 2 : 모델2 방식은 View와 Controller를 분리하는 방식이다. 따라서 디자이너와 개발자의 분업이 가능하며 유지보수에 유리하다.

• 단점 

  • Model 1 : JSP파일 자체가 너무 비대해지고, Controller와 View가 혼재하므로 향후 유지보수에 어려움을 겪을 수 있다.

  • Model 2 : 설계에서 어려움을 겪을 수 있고, 개발 난이도가 높다는 단점이 있다. 

> Model 1의 방식으로 웹 서비스를 개발하는 사례는 아예 없다고 봐도 무방하다고 한다.
   백엔드와 프론트엔드 역할 분담이 모호해서 오히려 협업에 걸림돌이 된다고. 

출처: https://wooaoe.tistory.com/15 [개발개발 울었다]

---

MVC 패턴이란?

모델-뷰-컨트롤러(Model–View–Controller, MVC)는 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다.
이 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다.
-wikipedia-

MVC pattern 은 프로그래밍을 할 때 전체적인 구조에 관련된 여러 디자인 패턴 중 하나이며, 도메인(비즈니스)로직과 UI로직을 분리하여 유지보수를 독립적으로 수행할 수 있게 하는 장점이 있다.

M (model, domain)

M은 Model을 가리킨다.
Model이란 프로그램이 작업하는 세계관의 요소들을 개념적으로 정의한 것이라고 볼 수 있다.
예를 들어 음식점 무인 포스기를 개발한다고 가정해보자. 무인포스기가 정상적으로 목표하는 작업을 수행하기 위해서는 우선 메뉴가 있어야하고, 메뉴를 담을 수 있는 장바구니, 해당 메뉴의 수량, 결제수단, 할인정책 등등이 필요할 것이다.

이처럼 프로그램이 목표하는 작업을 원활하게 수행하기 위해 필요한 물리적 개체, 규칙, 작업등의 요소들을 구분되는 역할로써 정의해놓은게 Model이 된다. Model은 DTO와 DAO로 분류할 수 있다.
두 개념에 대해서는 나중에 다른 세션에서 정리할 예정이므로 간단히 언급만하고 넘어가겠다.

결과적으로 Model을 잘 설계하는 것은, 해당 도메인 세계를 얼마만큼 이해하고 있는지와도 밀접한 연관이 있다. 꼭 물리적인 요소뿐만아니라 추상적인 요소 또한 해당 작업을 수행하는데 특정 책임과 역할로서 구분될 수 있다면 최대한 구체적이고 작은 entitiy를 유지하면서 Model을 설계하는 것이 중요하다.

V (view)

V는 View를 가리키고 사용자가 보는 화면에 입출력 과정 및 결과를 보여주기 위한 역할을 한다. 입출력의 순서나 데이터 양식은 컨트롤러에 종속되어 결정되고, 도메인 모델의 상태를 변환하거나, 받아서 렌더링하는 역할을 한다.

view를 구현할 때 주의할 점은 도메인 로직의 어떤 것도 알고 있으면 안된다는 것이다. 절대적으로 객체를 전달받아 상태를 바로 출력하는 역할만을 담당해야 한다. 그렇기 때문에 view에서는 도메인 객체의 상태를 따로 저장하고 관리하는 클래스 변수 혹은 인스턴스 변수가 있을 필요가 없다.

C (controller)

C는 Controller를 가리킨다. controller는 model과 view를 연결 시켜주는 다리 역할을 함과 동시에 도메인 객체들의 조합을 통해 프로그램의 작동 순서나 방식을 제어한다. controller는 view와 model이 각각 어떤 역할과 책임이 있는 지 알고 있어야 한다.

웹 프로그래밍에서는 Controller에서 service layer를 분리하여 domain 로직이 수행되는 곳과 view의 요청을 매핑하는 곳을 독립적으로 관리할 수 있다.

 

MVC 패턴 적용 시 고려해볼 만한 것들

1. TDD로 개발 할 수 있나?

• View
  뷰는 사용자의 동작과 연관되어 있는 부분이 많고, 비교적 자주 변경되는 부분이라 웹 애플리케이션 개발에서 많은 시간이 소요되는 영역이다. 때문에 뷰를 TDD로 개발하는 것은 효율이 낮을 뿐만 아니라 쉽지도 않다. 그리고 뷰에는 다양한 요소들이 혼재되어 있다. 그럼에도 보통은 이를 분리해서 생각하지 않고 뷰라는 한 가지 개념으로만 접근하기 때문에 더욱 어렵게 느껴지기 쉽다.

• Controller
  결론부터 이야기하자면, 컨트롤러에 대한 TDD 작성은 비교적 수월하다. MVC 모델에서 컨트롤러를 테스트하는 가장 간단한 방법을 소개하면 뷰로부터 넘어오는 요청 (Request)를 가상으로 만들어주고, 그 결과에 해당하는 응답이 예상과 일치하는지 판단하면 된다.
  모델 테스트보다는 귀찮고 복잡하지만 controller를 테스트하는 것도 충분히 가능하고, 프레임워크를 쓰면 manual로 하는 것보다 훨씬 수월하게 할 수 있다고 한다.

• Model
  MVC에서는 모델(model)과 뷰를 완전히 분리하는 방식으로 작성할 것을 권장한다. 모델이 통신하는 컨트롤러와의 관계도 사실 자세히 살펴보면 모델이 컨트롤러를 호출하는 경우는 없다. 모델은 오로지 무언가의 호출에 응답할 뿐이고, MVC 모델의 웹 애플리케이션에서는 컨트롤러가 모델을 호출하는 역할을 맡고 있을 뿐이다.
  혹자는 이런 방식을 객체 지향 원칙 중 하나인 헐리우드 법칙(Don’t ask me, I’ll tell you)이라고 부르기도 한다. 모델은 웹 애플리케이션 구성요소 중 가장 TDD 가 쉽게 적용되는 부분이고, 또 적용해야 하는 부분이다.

2. Controller는 하나만 만들어야 하는가?

위키에 나온 controller의 정의만 보더라도 위 물음에는 대답이 명확히 나온다.

MVC의 뷰는 여러 개의 컨트롤러(Controller)를 가지고 있다. 사용자는 컨트롤러를 사용하여 모델의 상태를 바꾼다. 컨트롤러는 모델의 mutator 함수를 호출하여 상태를 바꾼다. 이때 모델의 상태가 바뀌면 모델은 등록된 뷰에 자신의 상태가 바뀌었다는 것을 알리고 뷰는 거기에 맞게 사용자에게 모델의 상태를 보여 준다. - wikipedia-

따라서 controller는 하나일 필요가 없다. 프로그램이 실행될 때 로직이 병렬적으로 분기된다면 controller를 여러개 둬도 상관없다. 오히려 그게 더 깔끔한 설계가 될 수 도 있다.
최근 치킨집 포스기 구현 스터디를 통해 나도 새롭게 깨달은 부분인데 controller는 하나만있어야 된다는 나의 고정관념을 깰 수 있었던 좋은 귀감이 되었다. 적용 예시는 아래 코드로 대신한다.

처음 메인 기능을 선택하는 입출력 화면이 나오고, 유저의 입력에 따라서 각 controller가 실행된다.

public void run() {
        PosNumber posNumber;

        do {
            posNumber = getPosWithValidation();
            PosController controller = posNumber.getController();
            controller.controlAction(tables, menus); 
            // posNumber에 따라서 각각의 controller가 실행됨.
        } while (posNumber.isNotExit());
    }

각 컨트롤러는 Interface를 구현하는 방식으로 만들면, 유저 입력에 따라 if문으로 분기하여 controller를 실행하는 번거로움을 제거할 수 있고, 다형성을 이용하여 유지보수 및 확장할 때도 이점을 확보할 수 있다.

// PosController Interface
public interface PosController {
    void controlAction(Tables tables, Menus menus);
}

 

3. MVC 패턴의 장점은 무엇인가?

사용자가 보는 페이지, 데이터처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤, 이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할 수 있게 된다. 도메인을 작은 역할 단위로 분리하여 설계하는 것도 일종의 분업이라고 할 수 있지만 전체적인 구조에서도 MVC 패턴은 분업을 만들어 낼 수 있다.

서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발을 하고 그렇게 애플리케이션을 만든다면, 유지보수성, 애플리케이션의 확장성, 그리고 유연성이 증가하고, 중복코딩이라는 문제점 또한 사라지게 된다.

4. 그렇다면 MVC 패턴은 만능인가?

그렇지 않다. MVC 패턴도 수많은 디자인 패턴 중 단순하고 명료해서 기본적으로 많이 사용되는 패턴일 뿐, 한계점도 당연히 가지고 있다.

한 Model은 다수의 View들을 가질 수 있고 반대로 Controller를 통해서 한 View에 연결되는 Model도 여러 개가 될 수 있다.
이렇게 되면 결과적으로 View와 Model이 서로 의존성을 띄게 됩니다. 물론 설계를 잘 한다면 Model간의 의존성 뿐만아니라 View와 Model 사이에 생기는 의존성도 줄일 수 있지만, 프로그램 특성상 필연적으로 화면에 복잡한 화면과 데이터의 구성 필요한 구성이라면, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 생길 수 있다.

이렇게 MVC 규모 자체가 너무 복잡하고 비대해져서, 새 기능을 추가할때마다 의존성을 일일이 해결해야해서 메소드 분석이나 테스트도 어렵게 된다. 이런 형태의 MVC를 Massive ViewController라고 부르는데, 이는 MVC의 한계를 표현한 용어이기도 한다.

View와 Model을 중재하는 Controller의 비중은 별로 크지 않을 것으로 생각할 수 있지만, 복잡한 화면을 구현하게 되면 Massive ViewController가 될 수 밖에 없다.

Controller는 View와 라이프 사이클이 강하게 연결되어 있어서 분리하기도 어렵고, 유지보수와 테스트가 모두 힘들어진다.
이러한 한계점을 갖고 있기 때문에 MVC로 부터 파생된 다른 패턴들을 공부해보는 것도 나중엔 도움이 될 것이라고 생각한다.

 

 

출처 : velog.io/@ljinsk3/Concept-MVC-Pattern

---

MODEL

프로그램 내부 데이터 처리

DB와 연동하여 사용자가 입력한 데이터나 사용자에게 출력할 데이터를 다루는 역할
MODEL의 상태에 변화가 있을 때 CONTROLLER와 VIEW에 통보
비즈니스 로직과 데이터를 다루는 영역
비즈니스 데이터는 DBMS에 의해 관리되고 그 데이터를 다루는 연산은 SQL문을 통해 구현된다.
편집하고자하는 모든 데이터를 가지고 있어야 한다.
View나 Controller에 대하여 어떤 정보도 알지 말아야 한다.
변경이 일어나면 변경 처리 방법을 구현해야 한다.
데이터베이스 schema, 데이터 odbc, 쿼리문 등을 모두 가지고 있는 것 
Business Layer / Persistence Layer / Domain Model Layer

 

Business Layer

Service 클래스로 Controller 계층과 Persistence 계층 사이를 연결하는 역할로 두 계층이 직접적으로 통신하지 않게 하여 애플리케이션의 유연성을 증가->다른 계층들과 통신하기 위한 인터페이스 제공
핵심 업무를 어떻게 처리할 지에 대한 방법을 기술
트랜잭션 처리 

Persistence Layer

DAO(Data Access Object, 실제적으로 DB에 접근하는 객체) 클래스가 담당한다

데이터 처리 담당
데이터베이스에서 데이터를 빼내 객체화하며 데이터를 저장, 수정, 삭제하는 계층->데이터베이스나 파일에 접근하여 데이터를 CRUD하는 계층(Hibernate, ibatis, EJB)
|dataSource와 Connection Pool, Sql Mapping 담당

Domain Model Layer

데이터 객체를 의미
DTO는 VO(Value Object, 자바빈즈)와 밀접하다
일반적으로 DTO는 로직이 없이 속성과 속성에 접근하기 위한 setter, getter메소드만 가지고 있다
데이터베이스의 모든 정보를 일일이 객체로 만들기보다는 도메인 모델을 이용하여 서비스 

VIEW

사용자 인터페이스, MODEL에서 전달받은 데이터 출력
모델이 가진 정보를 따로 저장하면 안된다.
자바 웹 애플리케이션에서는 JSP를 통해 구현
MVC Model 2에서는 JSP가 그 역할을 한다

CONTROLLER

MODEL과 VIEW의 상호작용
클라이언트의 요청을 받아서 실제 업무를 수행하는 부분
클라이언트 요청에 대해 MODEL과 VIEW를 결정하여 전달
DB와의 접근이 필요하다면 MODEL을 통하여 DB에 접근한 뒤 받아온 데이터를 VIEW로 전달해준다
모델이나 뷰에 대하여 알고 있어야 한다.
MVC Model 1에서는 Servlet과 JSP가 같이 쓰이므로 JSP가 Controller 역할을 수행하게 되면서
프리젠테이션 로직과 비즈니스 로직의 분리가 어렵고 뷰의 재활용성이 떨어진다

MVC Model 2에서는 Servlet이다. 

작은 애플리케이션은 JSP 내에서 계층을 분리하지 않고 제어와 로직, 표현을 하나에 처리해도 문제가 발생하지 않고 생산성도 더 좋을 수 있으나 대규모 개발의 경우 각 기능을 확실히 나눠야만 개발자와 디자이너의 업무를 분리하여 프로그램의 유연성을 보장하고 확장성, 재사용성을 높일 수 있다. 

많은 시행착오 끝에 잘 구축된 컨트롤러들이 재활용되며 웹 프레임워크 형태로 보급됨

출처: https://na27.tistory.com/224