frontend 디자인패턴 🎀

Jyerr·2024년 7월 19일

오늘은 프론트엔드의 디자인 패턴에 관한 이야기를 해보겠습니다
일단 디자인 패턴이 무엇인가..에 대해 먼저 말해볼께요

🍿 디자인패턴

개발하면서 발생하는 반복적인 문제들 을 어떻게 해결할 것인지에 대한 해결 방안으로 실제 현업에서 비즈니스 요구 사항을 프로그래밍으로 처리하면서 만들어진 다양한 해결책 중에서 많은 사람들이 인정한 모범 사례(Best Practice)다.

이러한 디자인 패턴은 객체 지향 4대 특성(캡슐화, 상속, 추상화, 다형성)과 설계 원칙(SOLID)을 기반으로 구현되어 있다.

쉽게 말해서 개발할때 자주 만나는 문제들을 해결하기 위해 미리 구상한 해결방법의 전체적인 구조.. 라고 볼 수 있겠다!

디자인 패턴 하면 가장 유명한 패턴이 MVC 패턴이다

🍡 MVC

MVC 패턴은 View , Model , Controller 세가지 영역으로 나누어서 동작하도록 설계된 패턴이다.

📺 View

화면이다.
웹 프론트에서는 대개 최종적으로 HTML과 CSS로 만들어지는 결과물이다.

🔢 Model

소프트웨어가 다루는 데이터영역 이라고 보면된다

👮‍♂️ Controller

Model로 부터 데이터를 받아서 화면에 그리고 화면으로부터 사용자의 동작을 받아서 Model을 변경한다. 즉 Model과 View 중간에서 제어하는 역할을 한다.

MVC 패턴은 주로 벡엔드에서 유용하게 사용되는데

백엔드에서의 수행절차 본다면

Client의 Request를 받는다.

Request를 분석한다.

필요한 데이터를 수집/가공 한다.

뷰를 생성하고 Response한다.

이런식으로 동작하게 된다.
MVC에 적용하면

Request를 Controller가 받은 뒤 비즈니스 로직을 처리하여
결과를 Model에 담는다.
Model에 저장된 결과를 바탕으로 Controller는 시각적 요소 출력을 담당하는 View 를 제어하여
사용자에게 화면으로 전달하게 되는 것이다.

MVC가 이렇게 나눠진 이유는,

1️⃣ 화면을 다루는 문제와 데이터를 다루는 문제의 성격이 달라서 분리하고 싶고

2️⃣ Model과 View간의 의존관계를 최소화 해서 화면의 수정이 데이터수정에 영향을 미치지 않고 데이터 수정이 화면의 수정에 영향을 미치지 않고자 함이다

그렇다면 MVC패턴이 프론트에서도 유용할까?
정답은

❌

이다

이유를 보자면 프론트엔드는 그 자체가 View이기 때문에 MVC 패턴과 같은 처리보다는 그냥 View에 대한 처리가 필요한 것일 수 있기 때문이다.

프론트엔드에서의 View는 굉장히 복잡하다.

보통 MVC에서 View는 만들어지는 결정체일뿐이다.

하지만, 프론트엔드에서의 View는 온갖 이벤트가 발생한다.
결국 View가 메인이자 Controller와 같은 역할을 할 수 밖에 없는 상황이 되어버린다.

이런 FE 특성에서
Model 과 View의 관계를 보면

1️⃣ View -> Model

2️⃣ Model -> View

이런식으로 서로 양방향으로 통신을 하게 된다..

게다가
프론트에서는 View가 상당히 복잡해서 우리는 보통 잘게 나누고는 한다.

그렇게 되면 이런식으로 더 총체적 난국으로 복잡해지게 되는 결과가 나온다

서로간의 의존성도 많아지고
뷰와 모델간의 복잡성이 훨씬 증가한다

그러면 이 사이에 컨트롤러를 넣으면 되지 않냐고 할 수 있다.

그치만 그렇게 되면 이 컨트롤러는 복잡한 뷰와 모델을 모두 연결하고 있기때문에 굉장히 복잡하고 비대한 슈퍼 울트라 컨트롤러가 되버린다. 이러면 그냥 문제 해결이 아니라 더욱 더 복잡함을 ++++ 시킨다고 볼 수 있다.

따라서 MVC패턴은 프론트엔드 개발에는 유용하지 않다
실제 FE에서 대안으로 사용되는 기술들은

MVVM 아키텍처
FLUX 패턴

등이 있다.

🍡 MVVM

MVVM 패턴은 Model , View , ViewModel로 이루어져 있다.

Model과 View는 앞서 설명한 MVC 패턴에서와 비슷한 역할을 한다.

👷‍♀️ ViewModel

ViewModel은 View의 추상화이자 말그대로 뷰의 모델을 의미한다.
Controller와 비슷하게 뷰와 모델 사이의 어댑터 역할을 하지만
이를 구현하는 방식이 DOM 조작에서 템플릿과 바인딩을 통한 선언적인 방법이라는 점에서 차이점이 발생한다.

뷰와 뷰모델 / 뷰모델과 모델 사이의 관계를 살펴보며 더 자세히 알아보겠다.

🪄 View - ViewModel

뷰 모델은 뷰가 데이터바인딩 할 수 있는 속성과 명령을 구현하고 뷰에게 알린다.

➡️ ✨ 데이터바인딩은 View와 Model 사이의 데이터를 동기화하여 View가 Model의 상태를 반영하고, Model이 View의 상태를 업데이트할 수 있도록 해주는것이다.
뷰는 UI스레드를 차단하지 않은 상태로 유지해야하기 때문에 뷰모델에서 I/O 작업에 비동기 메서드를 사용하고, 이벤트를 발생시켜 뷰에 속성 변경 사항을 비동기적으로 알린다.

➡️ UI 스레드를 차단하지 않아야 된다는건 사용자가 애플리케이션과 상호작용하는 동안, 화면이 멈추거나 응답이 없으면 안된다는 것이다. 따라서 \ 데이터가 변경되었을 경우 뷰모델은 뷰에게 비동기적으로 알려둔다
뷰모델과 뷰는 1:N 관계를 유지한다.
➡️ 뷰모델은 뷰를 알지 못한다. 특정 뷰에 의존하지 않기 때문에 재사용이 가능하다,

🪄 ViewModel - Model

뷰 모델은 뷰가 쉽게 사용할 수 있는 형식으로 모델의 데이터를 가공해 제공한다
뷰 모델과 모델은 1:N 관계를 유지한다.
➡️ 모델은 뷰모델과 뷰. 그 누구도 알지 못한다. 따라서 뷰와 독립적으로 발전할 수 있다

MVC에서 MVVM으로 오면서 달라진 부분

1️⃣ 컨트롤러의 반복적인 기능이 선언적인 방식으로 개선이 되었다.

2️⃣ Model과 View의 관점을 분리하려 하지 않고 하나의 템플릿으로 관리하려는 방식으로 발전했다.

🍡 FLUX 패턴

FLUX 패턴의 포인트는 단방향 아키텍처라는 것이다.

기존의 MVC는 컴포넌트의 재사용과 독립성을 지나치게 강조하다보니 같은 데이터를 공유하는 과정에서 props을 통해서 데이터를 전달하는 문제들로 하여금 Model의 관리가 파편화 되는 문제가 발생했다.

그래서 FLUX 패턴이라고 하는 단일 흐름을 만들었으면 좋겠다라는 식으로 발표가 된다.

View에서 Action을 호출하면 Dispatcher를 통해 Store라는 공간에 Data가 보관이 되고 다시 뷰로 전달되는 흐름이다.

FLUX 패턴은 View를 각각의 MVC 컴포넌트 관점으로 보는 것이 아니라 하나의 큰 View로 이해하고 View에서는 Dispatch를 통해서 Action을 전달하면 Action은 Reducer를 통해서 Data가 Store에 보관이 되고 Store에 들어있는 데이터는 다시 View로 연결이 되는 방식을 지향한다

기존의 컴포넌트 단위의 MVC개념에서 완전히 비지니스 로직과 View를 분리하면서 이 분리된 개념을 상태관리(State Management)라고 부르게 된다

이 FLUX 패턴을 아주 잘 따르고 있는 상태 관리 라이브러리로 Redux가 있다.

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

1️⃣ 공통적으로 사용되는 비지니스 로직의 Layer와 View의 Layer를 완전히 분리되어 상태관리라는 방식으로 관리한다.

2️⃣ 각각의 독립된 컴포넌트가 아니라 하나의 거대한 View 영역으로 간주한다.

3️⃣ 둘 사이의 관계는 Action과 Reduce라는 인터페이스로 분리한며 Controller는 이제 양방향이 아니라 단반향으로 Cycle을 이루도록 설계한다.

이러한
FLUX 패턴에도 한계는 존재하는데