<aside> 🔎
아키턱쳐 패턴은 소프트웨어 설계의 기본이며 자주 사용되는 모형들을 정립한 하나의 약속이에요!
</aside>
대표적으로 MVC(Model-View-Controller)패턴과 MVVM(Model-View-ViewModel)패턴이 있는데요! 두 패턴 모두 UI와 데이터 처리 로직을 분리함으로써 유지보수를 용이하게 한다는 장점을 가지고 있어요. 각 패턴에 대해 조금 더 자세히 알아봅시다!
우리가 지금껏 사용해온(세미나, 합동세미나⋯) 패턴이 바로 MVC 패턴입니다. MVC 패턴은 뷰 컨트롤러가 뷰와 모델의 중간 다리를 해주는 구조로, 빠른 개발에 용이하다는 장점을 가지고 있어요!
Model: 데이터를 다루는 부분으로, 데이터를 파싱하기 위해 필요한 구조를 정의해요.
View: 화면에 보이는 UI
Controller: 뷰와 모델의 상호작용을 돕는 역할! 뷰와 모델을 모두 알고 있으며, 둘의 변경사항을 트래킹해요.
그렇지만! MVC 패턴은 Massive View Controller라고 불릴 만큼 뷰 컨트롤러에게 많은 책임을 안기고 있다는 단점이 있어요. 이는 SOLID 원칙 중 첫 번째인 SRP(단일 책임의 원리)를 어기고 있는 것이기도 해요. 한 객체가 이렇게 많은 일을 하고 있는 것은 객체 지향 프로그래밍에서 옳은 방법은 아니에요.
또한 MVC 패턴에서는 Model, View, Controller이 강하게 결합되어 있어, 한 요소의 변경이 다른 요소에 영향을 미치는 경우가 많아요! 예를 들어, 뷰의 디자인을 변경할 때 뷰를 사용하는 컨트롤러의 코드도 함께 수정해야 하는 경우가 많은 거죠. 이렇듯 강한 결합도의 문제는 유지보수와 확장성을 떨어뜨립니다.
그 외에도 코드 로직이 분산되어 있거나 이후 유닛 테스트에서 여러 어려움을 겪는 등의 단점이 존재해요!
MVC 패턴의 단점을 보완하기 위해 등장한 MVVM 패턴은 UI 로직과 비즈니스 로직을 분리하고 반응형으로 UI를 동작하게 구성해요!
Model: MVC 패턴의 모델과 유사하게 데이터를 다루는 부분을 의미해요.
View: UI를 다루는 로직 모두를 의미해요. (1) 사용자와 뷰의 상호작용을 수신하고, 이에 대한 처리를 뷰모델에 부탁해요. (2) 뷰모델로부터 데이터를 가져와 UI를 그려요.
ViewModel: 뷰와 모델 사이의 중간 다리 역할로, 비즈니스 로직을 처리하고, 뷰에 표시할 데이터를 가공해요.
<aside> 🔎
비즈니스 로직이란, UI 로직, 즉 라이프 사이클과 강력하게 연결되어 UI 변경에 관여하는 로직을 제외한 여러 기능 로직을 말해요. 서버 통신, 에러 처리, 비즈니스 규칙(유효성 검사)과 관련된 코드가 있어요.
</aside>