1. MVC구조
백엔드에서 유명한 디자인패턴으로 MVC가 있어서 이를 먼저 찾아봤지만. 프론트에서는 여러 이유로 해당 구조가 적용되기 어려웠다.
정리하면
- 뷰의 다양성: 프론트엔드에서는 다양한 UI 컴포넌트와 화면이 필요하기 때문에, 뷰가 많아진다. 이로 인해 관리가 복잡해질 수 있다.
- 양방향 의존성: MVC에서는 뷰와 모델 사이의 의존성이 강하다. 데이터가 변경될 때마다 뷰를 업데이트해야 하며, 사용자의 입력으로 모델을 업데이트해야 하는 경우도 있다. 이러한 양방향 의존성은 복잡성을 증가시킨다.
- 컨트롤러의 부하: 모든 중재 역할이 컨트롤러에 집중되므로, 컨트롤러는 복잡해지고 관리가 어렵다.
- 뷰의 계층: 사용자 인터페이스의 복잡성으로 인해, 뷰 간의 계층적 관계가 필요하게 된다.
와 같은 이유들이 있었다.
2. MVVM
위와 같은 상황에서 뷰와 모델사이의 관계를 단순하게 하고 view간의 계층적인 처리를 도울 수 있는 구조로서 MVVM이 존재한다.
Model: 데이터와 비즈니스 로직을 포함한다.
View: 사용자에게 보여지는 UI 컴포넌트다.
ViewModel: 뷰와 모델 사이의 다리 역할을 하는데, 사용자의 액션을 모델로 전달하고, 모델의 변경 사항을 뷰에 업데이트한다.
MVVM의 장점은 다음과 같습니다:
양방향 데이터 바인딩: 뷰와 뷰모델 사이의 자동화된 데이터 연결로 인해 코드 복잡성이 줄어든다.
모듈화 및 테스트 용이성: 뷰와 비즈니스 로직이 분리되어 있기 때문에 테스트하기 쉽다.
재사용성: ViewModel을 다양한 뷰에서 재사용할 수 있다.
이런 저런 정보를 더 찾아보다 아래 영상을 발견하게 되었다
[NHN FORWARD 22] Dooray! 모바일 앱의 클린 아키텍처 적용기
위 영상에서 기존 구조의 문제를 언급하고 해당 문제를 새로운 구조로서 해결하였는데 기존 구조가 우리 수준에서 크게 문제를 일으키지 않을 것 같고 MVVM을 쓰는 것보다 이점이 있어 이 구조를 선택하게 되었다.
우선 프레젠테이션 레이어와 데이터 레이어로 구분되고. 프레젠테이션 레이어에는 뷰, 뷰모델, 뷰 상태를 위치시키고, 데이터 레이어에는 데이터 소스와 API 모델을 배치하게 된다. 이 구조의 장점은 다음과 같다:
- 의존성의 명확성: 각 레이어와 컴포넌트 간의 의존성이 명확하게 정의됨으로써, 유지보수와 확장성이 향상된다.
- 데이터 흐름의 통일성: 데이터의 흐름과 처리가 일관되게 관리될 수 있어 복잡성을 줄일 수 있다.
- 재사용성 및 모듈화: 각 컴포넌트와 레이어가 독립적으로 작동하기 때문에 재사용성이 높아진다.
+그리고 나는 프론트 개발 경험이 아주 얕게 있고 다른 백엔드 개발자 친구는 프론트엔드 개발 경험이 전무한 상태이다. 이러한 상황에서 어떻게 분업을 하면 좋을까 생각했고 다른 백엔드 개발자 친구가 데이터 소스 및 api모델 파트의 리팩토링을 담당하고 양쪽에 대해 어느정도 지식이 있는 내가 뷰 모델과 뷰 상태를 세팅하고 프론트 친구가 이 뷰 모델과 뷰 상태를 이용하여 뷰를 구성한다면 적절한 자원분배가 될 수 있을 것 같다는 이유로도 이 구조를 선택하게 되었다.
나는 프레젠테이션 레이어와 데이터 레이어로 나누고 프레젠테이션 레이어에서 뷰 뷰모델 뷰상태, 데이터 레이어에서 데이터 소스, api모델 로 형성하고 싶어 데이터 소스는 api모델에 의존성을 갖고있고 뷰모델은 뷰 상태, 데이터 소스, api모델로 종속성을 갖고있어 뷰는 뷰 모델과 뷰 상태로 종속성을 갖고 있도록 구조를 짰다.
해당 구체적인 아키텍쳐의 내용은 아래 포스트에 있다.
