아키텍처 패턴(Architectural Pattern) 은 소프트웨어 설계 단계에서의 반복되는 문제를 해결하기 위한 방법론 으로, 시스템의 청사진 과 같습니다. 구축 단계에서 실제 구현에 사용되는 디자인 패턴(Design Pattern)과는 범위적으로 다르다고 할 수 있습니다.
목차 1. MVC 패턴
1. MVC 패턴 Model-View-Controller 조합의 설계 패턴으로,가장 흔히 사용되는 설계 패턴입니다.
MVC 패턴에선 Application을 비즈니스 로직, 화면, 컨트롤러 로직으로 나누어 설계합니다.
1) Model : 데이터, 비즈니스 로직, 규칙을 담당
2) View : Client에게 보여지는 UI를 담당
3) Controller : Client의 요청을 전달받고, Model/View의 상호작용을 담당
https://developer.mozilla.org/en-US/docs/Glossary/MVC
동작 과정 예시 1) View > Controller에게 Client의 요청을 전달
2) Controller > Model에게 필요한 데이터를 요청
3) Model > View에게 데이터를 제공
4) View는 데이터를 화면에 표시
위와 같이 Model과 View가 서로 상호작용할 수 있기 때문에, 결합도가 높아져 유지보수가 힘들 수 있습니다.
이에 대한 대안으로 MVP 패턴을 고려해볼 수 있습니다.
2 MVP 패턴 Model-View-Presenter 조합의 설계 패턴으로, MVC의 Controller 대신 Presenter가 역할을 대신하는 설계 패턴입니다. 각 구성요소와 역할이 MVC 패턴과 비슷하지만, 서로 상호작용하는 방법에서 약간의 차이가 있습니다.
1) Model : 데이터, 비즈니스 로직, 규칙을 담당
2) View : Client에게 보여지는 UI를 담당
3) Presenter : Client의 요청을 전달받고, Model/View의 상호작용을 담당
https://devscorch.com/?p=1460
동작 과정 예시 1) View > Presenter에게 Client의 요청을 전달
2) Presenter > Model에게 필요한 데이터를 요청
3) Model > Presenter에게 데이터를 제공
4) Presenter > View에게 데이터를 전달
5) View는 데이터를 화면에 표시
위와 같이 MVP 패턴에선 Model과 View가 서로 상호작용하지 않기 때문에, MVC 패턴과 비교해 결합도가 느슨해진 걸 알 수 있습니다. 하지만 오히려, Presenter와 View의 결합도가 높아진다는 단점도 있습니다.
3. MVVM 패턴 Model-View-ViewModel 조합의 설계 패턴으로, MVC, MVP 패턴과 비슷하지만 ViewModel이라는 요소가 데이터에 대한 비즈니스 로직을 수행한다는 점이 다릅니다.
MVVM 패턴의 ViewModel은 View의 존재를 모르고, View는 Model의 존재를 모릅니다.
ViewModel은 어떤 View가 자신과 연결되어 있는지 모르기 때문에, View의 디자인이나 DOM 요소가 변경되더라도 ViewModel에는 영향이 없습니다. 즉, 디자이너가 UI를 변경하더라도, ViewModel의 로직엔 영향이 없다는 것이죠.
Angular, React, Vue 등의 프레임워크들이 MVVM 패턴을 참고해 만들어졌습니다.
1) Model : 데이터 캡슐화를 담당
2) View : 오직 화면에 보여지는 UI만을 담당
3) ViewModel : View를 그리는 데 필요한 Model의 데이터를 가공하고, View와의 바인딩을 관리
MVVM 패턴은 뷰, 로직, 데이터로 영역이 명확히 나뉘기 때문에 단위 테스트, 유지보수에 강점이 있습니다.
반면, 코드의 규모가 비대해지기 때문에 작은 규모의 프로젝트나 시스템을 만들 땐 비효율적이라는 단점이 있습니다.
