챕터 8 추가

챕터_8/변수미.md

@@ -0,0 +1,102 @@
+## 8.1 MVC 패턴
+
+MVC 패턴은 애플리케이션의 구조를 개선하기 위해 **관심사의 분리를 활용**하는 아키텍쳐 디자인 패턴입니다.
+
+MVC : 비즈니스 데이터(모델)과 UI (뷰)를 분리하고, 세 번째 구성 요소(컨트롤러)가 로직과 사용자 입력을 관리하는 구조
+
+### 8.1.1 Smalltalk-80의 MVC 패턴
+
+1970년대에는 GUI라는 개념이 거의 존재하지 않아, 실제 세계의 아이디어를 모델링하는 **도메인 객체와** 사용자 의 화면에 렌더링되는 **프레젠테이션 객체 사이를 명확하게 구분하기 위한 수단**으로 **‘분리된 프레젠테이션(Separated Presentation)’** 이라는 개념이 유명해졌습니다.
+
+Smalltalk-80에서 구현된 MVC는 이 ‘분리된 프레젠테이션’ 개념을 한 단계 더 발전시켜 애플리케이션의 로직과UI를 분리하는 것을 목표로 했습니다 -> 모델을 애플리케이션의 다른 인터페이스에서도 재사용할 수 있음
+
+### 8.2.1 모델
+
+- 애플리케이션의 데이터를 관리
+- 모델이 변경될 때 관찰자에게 변경사항을 알립니다.
+- 비즈니스 데이터와 주로 관련이 있다.
+
+### 8.2.2 뷰
+
+- 모델에 대한 시각적인 표현, 현재 상태의 특정 부분만 보여준다.
+- 뷰는 모델을 관찰하고, 모델에 변화가 생기면 알림을 받습니다.
+- 사용자와 상호작용
+
+### 8.2.3 템플릿
+
+> 뷰는 애플리케이션 데이터를 시각적으로 표현하고, 템플릿은 뷰를 생성하기 위 해 사용될 수 있다.
+
+템플릿은 뷰와 연관되어있습니다.
+단, 템플릿 자체가 뷰는 아니라는 점을 명심해야 합니다. 뷰는 모델을 관찰하고 시각적 표현(UI) 을 최신 상태로 유지하는 객체입니다.
+프레임워크가 템플릿 명세에 따라 뷰를 생성할 수 있도록, 템플릿은 뷰 **객체의 일부 또는 전체를 선언적으로 지정하는 방법**이 될 수 있습니다.
+
+### 8.2.4 컨트롤러
+
+- 컨트롤러는 모델과 뷰 사이의 중재자 역할
+- 사용자가 뷰를 조작할 때 모델을 업데이트하는 역할
+- 애플리케이션 내에서 모델과 뷰 간의 로직 그 리고 연동을 관리
+
+## 8.3 MVC를 사용하는 이유는?
+
+MVC에서의 관심사 분리는 애플리케이션의 기능을 더 간단한 모듈로 나눌 수 있도록 해줍니다.
+
+- 전반적인 유지보수의 단순화
+  - 애플리케이션을 업데이트 할 때 변경사항이 데이터 중심, 시각적인 변경인지 명확하게 구분 가능
+- 모델과 뷰의 분리
+  - 비즈니스 로직에 대한 단위 테스트가 간편해짐
+
+## 8.6 MVP 패턴
+
+> 프레젠테이션로직의 개선에 초점을 맞춘 MVC 디자인 패턴의 파생
+
+### 8.6.1 모델, 뷰, 프리젠터
+
+MVP에서 P 는 프리젠터 Presenter를 의미 <- 뷰에 대한 UI 비즈니스 로직을 담당하는 구성요소
+
+MVC와달리,뷰에서의 이벤트호출은 프리젠터로 위임됩니다. (컨트롤러가 아닌 프리젠터로)
+프리젠터는 뷰와 분리되어 있으며, 인터페이스를 통해 뷰와 통신합니다.
+=> 단위 테스트에서 뷰를 모킹 할수있는 등의 많은 장점을 제공
+
+일반적으로는
+뷰의 요청에 따라, 프리젠터는 사용자 요청과 관련된 작업을 수행하고 데이터를 뷰로 다시 전달합니다.
+이를 위해 프리젠터는 데이터를 가져오고, 조작하고, 이 데이터가 어떻게 뷰에 표시되어야 하는지 결정합니다.
+
+### 8.6.2 MVP vs MVC
+
+MVP
+
+- 👍 프레젠테이션 로직을 최대한 재사용해야 하는 엔터프라이즈 수준의 애플리케이션
+- 👍 뷰가 매우 복잡하고 사용자와의 상호작용이 많은 애플리케이션
+  - MVC에서 여러 컨트롤러에 의존해야할 수 있어 👎
+  - MVP에서는 복잡한 로직을 프리젠터 안에 캡슐화 할 수 있음
+
+> MVC와 MVP 간의 차이점이 대부분 의미론적인 수준이므로, MVC에 존재하는 근본적인 문제점들은 MVP에도 동일하게 존재할 가능성이 크다.
+
+### 8.7.2 모델
+
+다른 패턴과 마찬가지로, 애플리케이션이 사용할 도메인 관련 데이터나 정보를 제공
+단, 데이터 유효성 검사를 모델에서 수행하는 것을 허용합니다.
+
+### 8.7.3 뷰
+
+다른 패턴과 마찬가지로, 뷰는 애플리케이션에서 사용자가 상호작용하는 유일한 부분이고, 뷰 모델의 상태를 표현하는 상호작용이 가능한 UI
+
+❗ 뷰는 상태를 관리할 책임이 없다는 것
+<- 뷰는 뷰모델과 정보 또는 상태를 항상 동기화된 상태로 유지하기 때문
+
+### 8.7.4 뷰모델
+
+데이터 변환기의 역할을 하는 특수한 컨트롤러
+모델의 정보를 뷰가 사용할 수 있는 형태로 변환하고, 뷰에서 발생한 명령 (사용자의 조작이나 이벤트)을 모델로 전달합니다.
+
+> 뷰모델은 UI계층의 뒤에 위치, 뷰가 필요로 하는 데이터를(모델로부터 가져와) 제공하며, 데이터와 사용자의 동작 모두를 뷰가 참조하는 출처의 역할
+
+## 8.8 장단점
+
+- 👍 UI를구동하게 해주는 요소를 동시에 개발할 수 있도록 합니다.
+- 👍 뷰를 추상화함으로써 뷰의 뒤에 작성되는 비즈니스로직의 양을 줄입니다.
+- 👍 뷰모델은 UI 자동화나 상호작용에 대한 고려없이도 테스트가 가능합니다.
+
+- 👎 단순한 UI의 경우, 과도한 구현이 될 수 있습니다.
+- 👎 대규모 애플리케이션에서는 필요한 일반화를 제공하기 위해 뷰모델을 미리 설계하는 것이 어려울 수 있습니다.
+- -> 적절하게 사용하기 어렵다