클라이언트 아키텍처 패턴 알아보자

sehwanforeal·2020년 8월 2일
1

클라이언트 아키텍처가 왜필요할까?

간단하다. 버그 발생률 줄이고, 이와같이 공통적으로 소프트웨어에서 발생하는 문제점들에 대응하기위해 클라이언트 아키텍처는 일반적이고 재사용가능한 해결책으로 등장했다.

현재까지 나온 아키텍처 패턴(MV로 시작하는것들)들을 정리해봐야겠다.

클라이언트 아키텍처 패턴에서 거의 항상 등장하는 개념이있다. 이는 리엑트의 경우에 컴포넌트 혹은 함수(hooks)로 분류된다.

  • Models

  • Views

  • Controller/Presenter/ViewModel

모델(Models)

도메인 데이타, 혹은 데이타를 담당하는 데이타 접근 계층을 나타낸다.

뷰(Views)

말그대로 보여지는부분, UI를 담당한다.

컨트롤러,프레젠터,뷰모델(Controller/Presenter/ViewModel)

위의 모델과 뷰를 연결해주는 역할을 한다. 보통 View에서 유저의 행동이 입력되면, Model이 알게하고, Model이 변경되었을때 이에 맞게 View도 변경되게한다.

약간 레이어를 분리하고 의존성 최소화하는게 클린아키텍쳐랑 비슷한 맥락인거같다..
이런 공통된 개념을 가지고 클라이언트 아키텍처 패턴은 발전해왔다. 애플에서 기여를 많이했다 카더라...

MVC(Model–View–Controller)

전통적인 패턴이다. 다른 패턴들의 기반이 되는 패턴인거같다.
View는 상태를 가지고있지않고, 컨트롤러에의해 컨트롤된다(?) 모델이 변경되었을때 컨트롤러에 의해 컨트롤된다. 이는 깔끔하겠지만, 위에 그림에서 보다싶이 이 3개의 엔티티들이 서로를 알고있어서(의존) 재사용성이 극혐이다. 개념이 간단해 처음 개발 편리성은 높겠지만, 확장성, 재사용성, 테스트등을 고려하면 다른패턴들에 비해 단점이 많다고한다(틀딱). 근데 애플에서 ios개발할때 저거 개념을 좀 바꾸고 사용했다고하는데 그건 모르게따.

MVVM(Model-View-ViewModel)


MVC의 단점을 해결해주는 패턴이다. 뷰와 모델의 직접 연결을 끊고 뷰모델이 이를 관리한다. ViewModel은 모델과 뷰와 바인딩되어 모델이 데이터를 조작,가공 할때 모델을 조작해 데이터를 획득해서 UI(View)에게 전달한다.
그림에서 보면 뷰 -> 뷰모델 -> 모델 순으로 종속성이 리엑트 처럼 단방향이다. 깔끔하쥬?

다른것들은 다음에알아보자..

profile
@FrontEnd

0개의 댓글