아키텍처 패턴, 디자인 패턴, MVC, MVP, MVVM

mvvm패턴에 대해서 공부하려 서치를 하니 누구는 디자인 패턴 중에 mvvm이 있다고 하고 누구는 아키텍처 패턴 중 mvvm이 있다고 해서,, 내가 아는 디자인패턴은 생구행 뿐인데 (생성,구조,행위 패턴). 그래서 디자인패턴을 다른 곳에서도 그렇게 부르는건가뭔가 혼동이 와서 공부하는 이 part. 

 

학습목표

1. 아키텍쳐 패턴이 무엇인지 알수있다.
2. 아키텍쳐 패턴과 디자인 패턴을 구분할 수 있다.
3, 아키텍쳐 패턴의 종류를 알 수 있다.

이어서 다음 글에서는  MVVM에 대하여 알아볼 것이다. 

소프트웨어 아키텍쳐 패턴이란?

- 시스템의 기본 구조이자 시스템을 구성하는 요소와 각 요소 간의 관계를 정의하는 일종의 청사진
- 소프트웨어의 전체적인 그림을 만드는 솔루션
- 주어진 상황에서의 소프트웨어 아키텍쳐에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션.
- 서로 다른 시스템과 환경에서 시도되고 시험된 바람직한 사례를 양식화하고 추상화한 기술
- 체계적인 소프트웨어 설계의 기본이며 자주 사용하는 모형들을 정립한 하나의 약속이라 볼 수 있다. 

 

아키텍쳐 패턴의 특징

- 시스템의 주요 속성을 결정하고, 개발 과정의 중요한 설계 결정을 통제하는 역할을 한다.
- 각 구조는 소프트웨어 요소, 이들 간의 관계, 요소와 관계의 속성으로 구성
- 확장가능하며 유지보수 가능한 유연한 소프트웨어 아키텍처를 만들기 위한 필수 원칙 SOLID (객체 지향 설계 원칙) 이 있다.

 

아키텍쳐 패턴 기본원리

1. 모듈화
- 시스템의 기능들을 모듈 단위로 나누는 것, 이때 모듈 개수는 적당히, 너무 많은 경우 통합비용이, 너무 적을 경우 모듈 하나의 개발 비용이 많이 들게 됨.
2. 추상화
- 전체적이고 포괄적인 개념 설계, 차례로 세분화, 구체화
3. 단계적 분해
- 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키며 분할
4. 정보 은닉
- 한 모듈 내부에 포함된 절차와 자료를 숨기며 독립적 수행을 가능캐 해, 다른 모듈이 접근하거나 변경하지 못하게 하기.

 

소프트웨어 디자인 패턴 이란?

- 소프트웨어 디자인에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책
- 프로그래머가 어플리케이션이나 시스템을 디자일할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 패턴

 

아키텍쳐 패턴과 디자인 패턴의 차이

- 아키텍쳐 패턴은 소프트웨어 디자인 패턴과 유사하지만 더 큰 범주에 속함.
- 소프트웨어 아키텍쳐패턴은 한 소프트웨어의 뼈대, 고수준의 기반을 담당하고 소프트웨어 디자인 패턴은 각각의 모듈들이 어떤 것을 하는지, 클래스의 범위, 함수의 목적 등 코드 수준의 디자인을 담당한다.
- 아키텍쳐 패턴은 더 큰 뼈대, 디자인 패턴은 코드 수준에서의 설계를 담당한다.

 

 

아키텍쳐 패턴의 종류

계층화 패턴 (Layered pattern)
클라이언트-서버 패턴 (Client-server pattern)
마스터-슬레이브 패턴 (Master-slave pattern)
파이프-필터 패턴 (Pipe-filter pattern)
브로커 패턴 (Broker pattern)
피어 투 피어 패턴 (Peer-to-peer pattern)
이벤트-버스 패턴 (Event-bus pattern)
MVC 패턴 (Model-view-controller pattern)
블랙보드 패턴 (Blackboard- pattern)
인터프리터 패턴 (Interpreter pattern)

 

MVC 패턴 (Model - View - Controller)

- mvc 패턴은 모델(Model), 뷰(View), 컨트롤러(Controller)의 세 부분으로 구성

- 가장 널리 사용 ?
- mvc패턴은 각 부분의 역할을 명확하게 분리함으로써, 코드의 가독성과 유지보수성을 높인다.

- 모델(Model) : 데이터와 비즈니스 로직을 처리, 데이터를 가져오고 변경하는 메서드를 가지고있으며, 데이터 변경 시에는 이를 관리하는 컴포넌트로 알린다.
- 뷰(View) : 사용자 인터페이스를 담당. 모델의 데이터를 보여주고, 사용자 입력을 받아 모델에 전달
- 컨트롤러(Controller) : 모델과 뷰 사이의 상호작용을 관리, 어플리케이션의 흐름을 제어, 뷰에서 입력을 받아 모델에 전달하거나, 모델에서 변경된 데이터를 가져와 뷰에 반영

장점)  - 구조가 단순하고 이해하기 쉬움
           - 다양한 프로젝트에 적용할 수 있다는 것
단점)  - 뷰와 모델 사이의 강한 결합으로 인해 테스트와 유지보수가 어려울 수 있다

MVVM  패턴 (Model - View - ViewModel)

- MVVM은 모델(Model), 뷰(View), 뷰모델(ViewModel)의 세 부분으로 구성

- MVC 패턴의 단점을 보완하기 위해 등장
- 뷰와 모델 사이의 결합을 줄이고, 데이터 바인딩을 통해 뷰와 뷰모델 사이의 상호작용을 자동화 한다.

장점) 뷰와 비즈니스 로직의 분리가 잘 되어있어, 코드의 재사용성과 테스트 용이성이 높다.
단점) 구현의 복잡성이 증가할 수 있다.

MVP 패턴 (Model - View - Presenter)

- MVP는 모델(Model), 뷰(View), 프레젠터 (Presenter)의 세 부분으로 구성

- 모델(Model) : 애플리케이션의 비즈니스 로직과 데이터를 담당하는 부분
- 뷰(View) : 사용자 인터페이스를 담당하는 부분, 모델에 직접 접근하지 않으며, 프레젠터를 통해 모델과 상호작용한다.
- 프레젠터 (Presenter) : 뷰와 모델 사이의 중간자 역할. 뷰로부터 입력을 받아 모델에 전달하고, 모델로부터 데이터를 받아 뷰에 전달합니다.

 

여기저기 많이 찾아보며 작성했는데 아래 블로그가 가장 설명을 잘해놓으셨다 ¡ 굿
한 번의 글로 이해하는 소프트웨어 아키텍처 패턴 ( MVC, MVP, MVVM )