프론트엔드 아키텍쳐를 알아보자 (1) MVC, MVVM, Flux

 

아키텍처가 뭔데요

Software architecture is the structure of structures of an information system consisting of entities and their externally visible properties, and the relationships among them

Dr. Jean-Claude Franchitti from New York University

여러 정의가 있지만,  더 효율적인 코드를 작성하기 위한 구조.라고 생각하면 될 것 같다.

 

1. MVC 아키텍처 (Model-View-Controller)

클래식 오브 클래식.

백엔드와 프론트엔드가 구분되지 않던 시절, 어플리케이션을 모델-뷰-컨트롤러로 분리하는 아키텍쳐이다.

 

Model

데이터를 주관하는 영역.

화면의 어딘가에는 실제의 데이터가 반영이 되어 나타나야 하는데, 이 데이터는 소프트웨어가 다룬다.

 

View

화면. HTML과 CSS로 만들어진 결과물.

쉽게 말해 사용자에게 정보를 표시하는 역할이다.

Controller

Model과 View의 중간 역할.

Model의 데이터를 받아서 화면에 그리고, View로부터 사용자의 동작을 받아서 Model을 변경한다.

 

 

클래식하게 사용되던 아키텍처이나, 프론트엔드와 백엔드가 분리되며 점차 *죽어버렸다.

*MVC in frontend is dead

View의 복잡도, View-Model간 복잡한 관계로 인해 Controller도 복잡해지며

MVC 패턴의 존재 의의가 희석될 수 있다.

 

2. MVVM 아키텍처 (Model-View-ViewModel)

1. View에서 사용자 입력 발생: 사용자의 동작에 따른 이벤트 발생

2. ViewModel에서 이벤트 처리: 이벤트가 ViewModel로 전달되고, ViewModel은 해당 이벤트에 맞는 로직 수행

3. Model 업데이트: ViewModel은 Model의 데이터를 변경 (사용자가 입력한 값을 Model에 저장/서버에서 데이터를 가져와 Model에 반영)

4. ViewModel에서 View에 데이터 전달: Model의 데이터가 변경시 ViewModel이 감지, View에 변경된 데이터를 전달

5. View 업데이트: View는 ViewModel로부터 받은 데이터를 바탕으로 화면을 다시 렌더링

 

MVC 패턴과 매우 유사하지만, Controller의 책임을 View Model에게 나눠줌으로써 문제를 해결하는 로직이다.

즉, Model과 View의 관점을 하나의 템플릿으로 관리하려는 방식으로 발전한 것.

• 코드에서 DOM을 조작하는 코드가 사라지고 이 기능들은 프레임워크가 담당
• 개발자는 화면에 그려져야할 데이터만 만들어서 프레임워크에 전달해주면 프레임워크가 알아서 그려준다

 

View Model

View와 Model 사이에서 Model을 알맞게 가공해 View에게 제공한다. (= 비지니스 로직 처리)

 

 

3. 컴포넌트 패턴, Container-Presenter 패턴

MVVM이 화면단위가 아니라 조금 더 작게 재사용 할 수 있는 단위로 만들어 조립하는 방식을 컴포넌트 패턴이라고 한다.

 

컴포넌트는 재사용이 가능해야한다는 원칙이 있기에,

• 비지니스 로직을 관장하는 컴포넌트를 Container 컴포넌트
• 데이터만 뿌려주는 형태의 컴포넌트를 Presenter 컴포넌트

최상단이나 1 depth에 Container를 두고 비지니스 로직을 관리하는 구조를 Container-Presenter 아키텍처라고 한다.

 

4. Flux

MVC 패턴의 경우, 컴포넌트의 재사용성과 독립성을 강조하다 보니 같은 데이터를 여러 컴포넌트가 필요로 할 때 문제가 발생한다.

대표적으로 *Model의 관리가 파편화되는 상황이 발생한다.

*Model 관리의 파편화: 컴포넌트들이 각각의 데이터 조각을 props로 받아 처리하다 보면, 데이터가 여러 곳에 흩어져 있는 느낌이 든다. 즉, 애플리케이션의 데이터 구조가 한 곳에서 통합적으로 관리되지 않고, 여러 컴포넌트에 나뉘어져 관리되는 상황을 말한다.

 

이 문제를 해결하기 위해 데이터의 흐름이 한 방향으로만 흘러가도록 하는 Flux 아키텍처가 등장했다

 

1. View: 사용자가 이벤트를 발생시킴

2. Actions: 이벤트를 나타내는 Action 객체 생성

3. Dispatcher: Action을 받아 Reducer에게 전달

4. Reducer: 기존 State와 Action을 바탕으로 새로운 State를 계산

5. Store: 새로운 State를 저장하고, View에게 변경 사실을 알림

6. View: 변경된 State를 반영하여 화면을 다시 렌더링

View

• 사용자 인터페이스
• 사용자의 입력(Input)을 감지하고, 이를 Actions으로 변환하여 Dispatcher에게 전달

Actions

• View에서 발생한 사용자의 입력을 표현하는 객체
• 어떤 일이 발생했는지를 나타내는 메시지 역할

Dispatcher

• Actions을 받아 Reducer에게 전달하는 중앙 집중식 허브 역할
• 각 Action에 대해 단 하나의 Reducer만 호출하도록 보장

Reducer

• Actions을 기반으로 State를 변경하는 순수 함수
• 이전 State와 Action을 입력받아 새로운 State를 반환

Store

• 애플리케이션의 상태(State)를 저장하는 객체
• Reducer에서 변경된 State를 저장하고, View에게 변경 사실을 알린다.

 

cf. 3분만에 flux 이해하기

 

 

Flux 패턴을 이용한 구현체가 그 유명한 Redux이다.

 

 

 

 

 

 

ref

https://velog.io/@teo/프론트엔드에서-MV-아키텍쳐란-무엇인가요

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

https://www.freecodecamp.org/news/the-model-view-controller-pattern-mvc-architecture-and-frameworks-explained/

The Model View Controller Pattern – MVC Architecture and Frameworks Explained

https://velog.io/@minboykim/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%97%90%EC%84%9C-MVC

프론트엔드에서 MVC??

https://www.digitalocean.com/community/tutorials/android-mvvm-design-pattern

Android MVVM Design Pattern | DigitalOcean

 

 

 

https://www.patterns.dev/

↑패턴 공부하기 좋습니다.

Patterns.dev