아키텍처와 MV* 패턴에 관하여
참고자료
아키텍처란,
특별한 규칙 → 패턴 → 아키텍처
1) MVC 패턴
사실 어떤 서비스라고 하는 것이
사용자 ↔ FE ↔ BE ↔ DB 이 안에서 이뤄지는 것이고 더 간단히는
데이터를 어떻게 사용자에게 예쁘게 뿌려줄 것이냐 하는 것이다.
- View : 화면 (html, css)
-
Model : 데이터
화면 어딘가에 데이터가 반영이 되어야 한다.
- javascript의 object
- API
- DB
-
Controller
Model 과 View 사이에서 중간 역할을 하는것 (화면에 숨결을 불어넣는 부분)
다시 정리하면
데이터(Model)을 어떻게 사용자(View)에게 예쁘게(Controller) 뿌려줄 것이냐
와 같다.
기존에는, 위의 MVC 패턴의 형식을 구분하기를
- Model : DB
- View : Html, Css, Javascript
- Contoller : 데이터를 처리하고, html 을 만들어서 보여주는 영역
모두 SSR이였기 때문에 (.NET, JSP등)
2) MVVM 아키텍처
템플릿 바인딩을 해준다가 핵심 → Angular 에서부터 시작
Model 이 변하면, View를 수정하고, View에서 이벤트를 받아서 Model을 변경한다. Model→View,View→Model (MVVM)
- Model 변경 → View 수정 (반영)
- View 이벤트 발생 → Model 업데이트
3) 컴포넌트 그리고 Container-Presenter 패턴
MVVM 패턴으로 생산성이 확대 되었는데
여기에서 더 작은 사이즈로 재사용 가능한 단위로 만들어서 조립하는 방식을
Component Pattern 이라고 한다.
여기서 중요한게, 컴포넌트의 재사용이 가능해지려면 비즈니스 로직을 포함시키면 안된다
비즈니스 로직이 들어가게 되면 컴포넌트의 재활용성은 상당히 떨어지게 되기 때문
그래서 비즈니스 로직을 관장하는 Container Component와
데이터만 뿌려주는 Presenter Component로 분리하여 사용하는 방식을
Container-Presenter 패턴이라고 한다.
4) Flux 패턴과 Redux
컴포넌트로 잘개 쪼개지면 쪼개질수록 Props Drilling 이라는 문제가 발생하게 된다.
Redux의 등장으로 전역적인 상태관리가 가능해졌다.
그러나, 높은 학습곡선, 장황한 문법등이 문제임
5) Observer-Observable Pattern
몰라 복잡함
6) Context, hook, props 상속
- View Model은 분리하는게 맞다
- Context의 Provider와 Consumer 를 통해 필요한 데이터를 전달한다.