기술 면접: MVC 패턴

MVC 패턴이 무엇인가요?

Model-View-Controller는 소프트웨어 디자인 패턴 중 하나로 애플리케이션을 모델, 뷰, 컨트롤러로 구성한다.

이때 모델은 데이터를 관리, 데이터베이스와의 상호 작용 등을 처리.
뷰는 사용자 UI를 구성, 모델에서 가져온 데이터를 표시.
컨트롤러는 모델과 뷰간의 상호 작용을 관리, 사용자 입력을 처리하며, 모델의 데이터를 업데이트하고 뷰에 반영.

MVC 패턴은 각각의 구성요소가 독립적으로 작동하여 유지보수와 확장성을 향상하고
애플리케이션의 논리적인 구조를 분리함으로써 유연성을 높이고 개발 속도를 빠르게 할 수 있다.

MVC 패턴을 사용하는 이유는 무엇인가요?

MVC 패턴은 웹 개발에서 많이 사용되는데, 이는 웹 애플리케이션에서 데이터, UI 및 비즈니스 로직을 분리하는 데 매우 효과 적이기 때문이다.
MVC 패턴은 유지보수성과 확장성을 높이고, 개발 속도를 빠르게 할 수 있다. 즉, 모델, 뷰, 컨트롤러를 분리함으로 개발자는 각각의 구성 요소를 별도로 개발할 수 있으며, 분리된 구성 요소를 조합하여 애플리케이션을 완성할 수 있다. 또한 구성요소가 독립적으로 작동하기 때문에, 병렬 개발이 가능해져서 개발 속도를 높일 수 있다.

 

MVC 패턴을 사용할 때 지켜야 할 점이 무엇인가요?

 MVC 패턴에서 모델은 뷰와 컨트롤러에 의존하지 않아야 한다.
뷰는 모델에만 의존해야하고 컨트롤러에 의존하지 않아야 한다. 그리고 모델로부터 데이터를 받을 때, 반드시 컨트롤러에서 데이터를 받아야 하고, 사용자마다 다르게 보여주어야 하는 데이터만 받아야 한다.
컨트롤러는 모델과 뷰에 의존해도 된다.

 

MVC의 구성요소(모델, 뷰, 컴포넌트)에 대해 자세히 설명해 주세요

모델: 데이터와 비즈니스 로직을 담당하는 부분. 데이터베이스, API를 통해 데이터를 가져오고 가공하는 역할
뷰: 사용자에게 데이터를 시각적으로 표현하는 부분이다. HTML, CSS, JavaScript 등을 이용하여 UI를 제공.
컨트롤러: 모델과 뷰를 연결해 주는 역할이다. 사용자의 요청을 받아 모델에게 데이터를 요청하고, 그 결과를 뷰에게 전달한다. 또한, 사용자의 입력을 받아 해당하는 로직을 수행하는 역할도 한다.

컴포넌트는 MVC 패턴과는 조금 다른 개념이다. 컴포넌트는 일종의 재사용 가능한 UI 조각으로서, Vue.js나 React 같은 프런트엔드 프레임워크에서 사용된다. 컴포넌트는 독립적인 기능을 가지며, 필요에 따라 조합하여 사용할 수 있다. 이는 MVC 패턴의 뷰와도 유사한 개념이지만, 더 세부적인 UI 컨트롤을 담당하는 부분이다.

 

MVC 패턴의 문제점은 무엇이고, 해결책은 무엇인가요?

· View와 Model 사이의 의존성이 높음
· View와 Model의 높은 의존성은 애플리케이션이 커질수록 복잡해지고, 유지보수가 어려움

이러한 문제들은 다른 아키텍처 패턴을 고려할 필요성을 보여줍니다. 따라서, 개발자는 적절한 아키텍처 패턴을 선택하고 사용해야 합니다.

 

MVC 패턴의 대안이 있다면 알려주세요.

뷰와 모델 간의 데이터 바인딩을 쉽게 구현하고자 할 때, 뷰 모델을 이용하여 뷰와 모델  간의 의존성을 해결하고자 할 때 MVVM 패턴을 사용.
복잡한 애플리케이션에서 상태 관리를 효과적으로 하고자 할 때, 액션과 상태를 이용하여 예측 가능한 데이터 흐름을 구현하고자 할 때 FLUX 아키텍처 사용.
상태 관리를 중심으로 구현하고자 할 때, 불변성을 강조하여 상태 관리의 복잡성을 줄이고자 할 때
Redux 아키텍처 사용.

 

 

대답 못한 꼬리 질문: MVC 패턴을 사용하는 프레임워크나 라이브러리

Ruby on Rails, AngularJS, Spring Framework, Django
이 외에도 MVC 패턴을 사용하는 다양한 프레임워크나 라이브러리가 있습니다.

--- 받은 피드백

모르는 부분에 대해서 ..한것 같다 하지 않기, 설명을 더 명확하게 해야 할 것.
MVP, MVVM, Flux, Redux에 대한 공부도 해야 할 것 같다.

---

MVVM 아키텍처 - angular, react, vue

MVVM 패턴은 MVC 패턴의 한계를 극복하면서도 MVC 패턴의 장점을 유지할 수 있는 대안으로 등장.
MVVM 패턴은 MVC 패턴에서 View와 Controller 사이에 ViewModel이 추가된 형태입니다.
ViewModel은 View와 Model 사이의 데이터를 중개하고,
View에서 Model로의 직접적인 접근을 제한함으로써 복잡성을 줄입니다.

 

MVVM에서 템플릿과 바인딩

템플릿(Template)은 UI(User Interface)에서 자주 사용되는 개념 중 하나로, 화면에 표시되는 HTML 코드의 뼈대를 작성하는 데 사용됩니다. 일반적으로 UI 구성 요소 (예: 텍스트, 버튼, 이미지 등)의 위치와 레이아웃을 정의하고, 그리고 데이터를 바인딩하기 위해 특정 태그를 사용합니다.
바인딩(Binding)은 템플릿과 데이터를 연결하는 프로세스입니다. 즉, 바인딩은 데이터 모델과 UI 컴포넌트 사이에 연결고리를 만드는 것입니다. 데이터 모델에 변경 사항이 발생하면, UI 컴포넌트가 자동으로 업데이트되어 새로운 데이터가 표시됩니다. 이를 통해 개발자는 데이터 모델과 UI 컴포넌트 간의 복잡한 연결을 수동으로 관리하지 않고도 효율적으로 UI를 업데이트할 수 있습니다.
즉, 템플릿과 바인딩은 UI를 쉽게 작성하고 유지보수할 수 있도록 도와주는 기술입니다. 이러한 기술은 대부분의 모던 프런트엔드 프레임워크 및 라이브러리에서 사용됩니다. 예를 들어, AngularJS에서는 템플릿과 바인딩을 사용하여 양방향 데이터 바인딩을 지원하며, React에서는 JSX를 사용하여 템플릿을 작성하고, 데이터는 컴포넌트 속성으로 전달됩니다.

 

MVVM 이점

ViewModel을 사용하면 View와 Model 사이에 의존성이 제거됩니다. 이로 인해 View와 Model이 서로에게 영향을 주지 않으면서 독립적으로 변경될 수 있습니다.  View와 Model 간에 존재하는 복잡한 의존성을 간소화시킬 수 있으며, 이는 테스트를 더욱 용이하게 만듭니다.
ViewModel을 사용하면 UI를 업데이트하는 데 필요한 데이터의 양이 줄어듭니다. 이는 유지보수성을 향상하고 코드의 가독성을 높입니다.
MVVM 패턴에서는 양방향 데이터 바인딩을 지원하며, 이는 UI 개발의 생산성을 향상합니다.

MVVM 패턴에서도 여전히 양방향 데이터 흐름이 발생할 수 있으며, 이로 인해 복잡성이 증가할 수 있습니다.
이에 대한 대안으로 나온 패턴이 Flux 패턴입니다.

 

FLUX 패턴

Flux 패턴은 Facebook에서 만든 아키텍처 패턴으로서, 단방향 데이터 흐름을 강조합니다. 이 패턴에서는 데이터가 일방향으로 흐르기 때문에, 양방향 데이터 바인딩이나 서로 다른 컴포넌트 간의 의존성을 줄일 수 있습니다.
Flux 패턴은 Action, Dispatcher, Store, View로 구성됩니다.

Action: 사용자 입력 또는 시스템 이벤트와 같은 외부 요소에서 발생하는 모든 이벤트를 캡슐화합니다.
Dispatcher: Action을 처리하고 Store로 전달합니다.
Store: 애플리케이션의 상태를 저장하고, Action에 대한 응답으로 데이터를 변경합니다.
View: Store에서 데이터를 가져와 UI를 업데이트합니다.

Flux 패턴은 데이터 흐름이 단방향으로 흐르기 때문에, 애플리케이션의 복잡성이 줄어들고, 유지보수성이 높아지며, 디버깅이 용이해집니다. 또한, 컴포넌트 간의 의존성이 줄어들기 때문에, 코드를 재사용하기가 더욱 쉬워집니다.
따라서, Flux 패턴은 MVVM 패턴의 한계를 극복하면서도, 더욱 단순하고 유지보수성이 높은 아키텍처 패턴으로 등장하게 되었습니다. 현재 React와 같은 모던 프런트엔드 프레임워크에서 Flux 패턴을 기반으로 한 Redux 라이브러리를 사용하여 상태 관리를 처리합니다.

 

FLUX 패턴 단점 => 대안

구현이 복잡하다는 점과 데이터 흐름이 일방향으로 고정되어 있기 때문에, 일부 상황에서는 데이터를 업데이트하는 것이 어려울 수 있다는 점입니다. 또한, Flux 패턴에서는 Store가 불변성(Immutability)을 유지해야 한다는 점도 있습니다.

이에 대한 대안으로 나온 패턴은 Redux입니다. Redux는 Flux 패턴의 개념을 기반으로 하지만, 단점을 보완하고 개선한 패턴입니다. Redux에서는 상태(State)를 불변 객체(Immutable Object)로 관리하고, 불변성을 유지하면서 상태를 업데이트합니다. 또한, 애플리케이션의 모든 상태가 하나의 객체(Tree)에 저장되어 있기 때문에, 디버깅이 용이하고, 상태 관리가 간편합니다.

Redux는 Action, Reducer, Store, View로 구성됩니다.
Action: 사용자 입력 또는 시스템 이벤트와 같은 외부 요소에서 발생하는 모든 이벤트를 캡슐화합니다.
Reducer: Action을 처리하고 상태를 업데이트합니다.
Store: 애플리케이션의 상태를 저장합니다.
View: Store에서 데이터를 가져와 UI를 업데이트합니다.

Redux는 Flux 패턴의 단점을 보완하고 개선한 패턴으로서, React와 같은 모던 프런트엔드 프레임워크에서 많이 사용됩니다. 또한, Redux는 React와 함께 사용할 수 있도록 설계되어 있기 때문에, React와 함께 사용하면 상태 관리가 더욱 편리해집니다.

 

PHP

Hypertext Preprocessor는 서버 측 웹 개발 언어 중 하나로, HTML 문서를 동적으로 생성하고 데이터베이스와 상호 작용하며 웹 애플리케이션을 개발하는 데 사용된다. 오픈 소스이며 다양한 운영 체제와 웹 서버에서 사용될 수 있기 때문에 유연한 언어이다.

 

JSP

JavaServer Pages는 서버 측 웹 개발 언어 중 하나로, HTML 내부에 Java 코드를 포함시켜 동적으로 웹 페이지를 생성하는 데 사용된다. Java 언어를 기반으로 하기에 Java의 모든 기능을 사용할 수 있고,

Java Servlet 기술에 기반하여 동작하고, Java Servlet API를 사용하여 서버 측 로직을 작성할 수 있다.

Java 코드와 HTML 코드가 혼합된 형태로 작성되며, 클라이언트 요청이 있을 때마다 서버에서 Java 코드를 실행하여 동적으로 HTML 코드를 생성한다. 이를 통해 웹 페이지가 개인화되거나, 데이터베이스와 상호 작용하여 동적으로 데이터를 표시할 수 있다.

 

Servlet

Servlet은 Java를 기반의 웹 애플리케이션 개발에 사용되는 기술이다. Servlet은 클라이언트의 요청을 처리하고, 동적인 콘텐츠를 생성하며, 이를 HTTP 프로토콜을 이용하여 웹 서버와 통신한다. Java 웹 애플리케이션 서버에서 동작하며, 서버 측에서 실행되기 때문에 브라우저에 비해 빠르고, 동적인 웹 애플리케이션 개발이 가능하다. Servlet은 HttpServlet 클래스를 상속하여 구현하며, doGet(), doPost()와 같은 메서드를 오버라이드하여 서블릿을 구현한다.

 

오버라이드

상속 관계에서 자식 클래스에서 부모 클래스의 메서드를 재정의 하는 것.

 

doGet(), doPost() 메서드

 

doGet()은 HTTP GET 요청에 대한 응답을 처리. 주로 웹페이지 조회, 검색 시 사용.

URL에 매개변수를 전달할 수 있으며, 보안성이 낮아 사용자 입력을 전달하기에 적합하지 않음.

 

doPost()는 HTTP POST 요청에 대한 응답을 처리. 주로 데이터를 전달, 수정 시 사용.

URL에 매개변수를 전달하지 않고, HTTP 메시지 본문에 데이터를 담아 전달하기 때문에 보안성이 높음.

 

두 메서드 모두 요청 객체('HttpServletReauest')와 응답 객체('HttpServletResponse')를 매개변수로 받는다.

요청 객체를 통해 클라이언트로부터 전달된 데이터를 받고, 응답 객체를 통해 서버에서 클라이언트로 데이터를 보낸다.

 

Props Drilling

Props Drilling Problem은 컴포넌트 트리의 깊은 단계에서 Props가 전달되는 경우, 매우 많은 수의 중간 컴포넌트를 거쳐야 하기 때문에 Props 전달이 비효율적이 되어 성능 저하를 초래하는 것을 말한다.

이를 해결하기 위해서는 React Context나 Redux(FLUX 패턴)와 같은 상태 관리 라이브러리를 사용하여
Props Drilling을 최소화할 수 있다. 또한 React.memo나 shouldComponentUpdate와 같은 최적화 기술을 사용하여 컴포넌트의 불필요한 렌더링을 방지할 수도 있다.

 

 

---

FLUX 패턴과 Redux

FLUX패턴은 MVC의 개념에서 벗어나서 단방향 아키텍처 (uni-directional architecture)를 만들자는 이야기로 시작한다. (Model의 관리가 파편화되는 문제)

 

MVC에서 FLUX로 오면서 달라진 부분

 

•  공통적으로 사용되는 비즈니스 로직의 Layer와 View의 Layer를 완전히 분리되어 상태관리라는 방식으로 관리
•  각각의 독립된 컴포넌트가 아닌 하나의 거대한 View 영역으로 간주
•  둘 사이의 관계는 Action과 Reduce라는 인터페이스로 분리하며 Controller는 이제 양방향이 아닌 단방향 Cycle을 이루도록 설계

 

Redux, Vuex 등이 대표적인 상태관리 라이브러리이다.

 

https://velog.io/@teo/%ED%94%84% EB% A1% A0% ED% 8A% B8% EC%97%94% EB%93% 9C% EC%97%90% EC%84%9C-MV-%EC%95%84% ED%82% A4% ED%85% 8D% EC% B3%90% EB% 9E%80-%EB% AC% B4% EC%97%87% EC% 9D% B8% EA% B0%80% EC% 9A%94

프론트엔드에서 MV* 아키텍쳐란 무엇인가요?