post : 아키텍처 MV 에 관한 글

Author: navskh

_posts/Portfolio/2024-07-08-아키텍처패턴에 관하여.md

@@ -0,0 +1,100 @@
+---
+categories: [Refactoring]
+layout: post
+title: 아키텍터와 MV 패턴에 관하여
+subtitle : 리팩토링
+tags: [Refactoring]
+author: Young
+comments : True
+---
+
+# 아키텍처와 MV* 패턴에 관하여
+
+참고자료 
+
+[프론트엔드에서 MV* 아키텍쳐란 무엇인가요?](https://velog.io/@teo/프론트엔드에서-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 를 통해 필요한 데이터를 전달한다.