1. [회고 발표]
Goal SSG 명언 프로그램에서 배웠던 Contoller, Repository, Service와 관련해서 이것을 이해하기 위해 필요한 객체 지향 개념들을 정리해 보았습니다.
1-a. Separation of Concerns
SoC (Separation of Concerns)는 각 파티션이 별도의 관심사를 담당하도록 소프트웨어 시스템을 분할하여 복잡성을 관리하고 관심사의 중복을 최대한 최소화하는 설계 원칙이다. 아래 그림과 같이 컴퓨터 프로그램을 기능이 가능한 한 겹치지 않는 별개의 리소스로 나누는 프로세스를 말한다.
관심사란?
컴퓨터 프로그램 코드에 영향을 미치는 정보의 집합이며 코드 최적화가 필요한 하드웨어의 세세한 부분만큼 포괄적이거나 시작할 클래스의 이름처럼 구체적일 수 있다.
SoC 장점
SoC는 소프트웨어 시스템의 복잡성을 줄여 변경에 필요한 노력을 줄이고 소프트웨어의 전반적인 품질을 향상시킨다.
객체 지향 프로그래밍에서
Module A라는 class에 여러 역할들을 부여한다면, A class에 의존하는 모든 client objects들 수정이 필요할 경우 유지보수 작업 과정은 굉장히 힘들어지게 된다. 그래서, 좋은 객체 지향 프로그래밍 원칙에는 하나의 클래스에는 하나의 책임 (한 가지의 기능)만 갖도록 하는 원칙인 SRP (Single Responsibility Principle)가 존재한다.
SRP - 단일 책임 원칙
각 클래스에 변경 이유를 하나만 제공한다.
•
“Reason to change” == “responsibility”
•
An example: The invoice class does not have a responsibility to print itself.
MVC, MVP, MVC-N, MVVM, VIPER 과 같은 architectural 패턴들은 “프로그램의 유지보수를 쉽게 그리고 단위 테스트를 할 수 있게” 라는 공통된 목표를 가진다. 이 중 대표적인 관심사 분리 기법 중 하나인 mvc 패턴에 대해 알아보자!
1-b. MVC Pattern
MVC란? 하나의 application or project를 구성할 때, Model, View, Controller와 같은 세 가지 components로 구성된 architectural pattern이다. 아래의 그림처럼 사용자가 Controller를 조작하면 Controller는 Model을 통해 데이터를 가져오고 그 데이터를 바탕으로 View를 통해 시각적 표현을 제어하여 사용자에게 전달하게 됩니다.
•
Model: The backend that contains all the data logic
•
View: The frontend or graphical user interface (GUI)
•
Controller: The brains of the application that controls how data is displayed
Controller
컨트롤러는 사용자 입력을 받아들이고 이를 모델 또는 뷰에 대한 명령으로 변환한다. Model과 View 구성 요소 간의 인터페이스 역할을 한다. 계산기 프로그램에서, 사용자가 숫자를 입력함으로써 View에 변화를주면, Controller는 View로 입력된 값을 Model로 전달해주는 역할을 합니다. 또한 Model에서 값이 계산되면 그 값을 Controller는 View에 전달하여 계산된 값으로 화면을 갱신한다.
Model
모델은 데이터에 관한 로직을 담는 부분이다. 사용자 인터페이스로부터 독립적인 애플리케이션의 동적 데이터 구조로 이 패턴의 central component이다. 애플리케이션의 data, logic, and rules 관리를 직접 담당하며 컨트롤러로부터 사용자 입력을 받는다. It corresponds to all the data-related logic that the user works with. 계산기 프로그램을 만든다고 가정하면 값들을 계산하고 저장하는 부분이라고 할 수 있습니다.
View
View는 사용자에게 보여지는 화면을 가르키며 표시 및 표현 논리를 처리한다. For example, what the user sees (HTML, CSS, JS from the user's perspective). 계산기 프로그램이 있다면 계산된 값들이 보여지는 UI이다.
MVC를 사용하는 이유는?
•
여러 개발자가 모델, 컨트롤러 및 뷰에서 동시에 작업할 수 있다.
•
MVC를 사용하면 컨트롤러에서 관련된 작업을 함께 논리적으로 그룹화할 수 있다.
•
MVC framework의 본질은 모델, 뷰 또는 컨트롤러 간의 결합이 낮다는 것이다.
•
책임 분리로 인해 향후 개발 또는 수정이 더 쉽다.
•
모델은 multiple views를 가질 수 있다.
결과적으로 프로그램이 커져도 유지보수가 상대적으로 쉽다는 장점을 가진다.
Spring MVC
Framework
1.Client가 Request를 보낸다.(Ajax, Axios, fetch등..)
2. Request URL에 알맞은 Controller가 수신 받는다. (@Controller , @RestController)
3. Controller 는 넘어온 요청을 처리하기 위해 Service 를 호출한다.
4. Service는 알맞은 정보를 가공하여 Controller에게 데이터를 넘긴다.
Service가 비즈니스 로직을 수행하고 데이터베이스에 접근하는 DAO를 이용해서 결과 값을 받아온다.
5. Controller 는 Service 의 결과물을 Client 에게 전달해준다.
1-c. Controller, Service, and Repository
SSG 명언 시스템에서는 어떻게 작동하는지 살펴보자!
Controller는 데이터가 제대로 들어왔는지 유효성 체크한다
=> info desk 직원과 같이 고객을 응대한다.
Java
복사
•
이제 요리사에게 toss -> Service (서비스)
서비스는 비지니스 로직 처리한다.
=> 실제 요리를 한다. But, 재료 손질, data management는 X
리포지터리는 데이터 관리를 관리한다.
=> 창고직 role,
음식 창고가 있으면 배추를 자르는 것과 같은 단순한 업무만 한다.
Java
복사
•
Overall Flow
고객(USER)이 점원(controller)에게 요청하고 점원은 요리사에게 요리사(service)가 재료 담당 직원(Repository)에게 리포지토리는 재료 창고(DB)한테
점원(controller)에게 요청하고 점원은 요리사에게 요리사(service)가 재료 담당 직원(Repository)에게 리포지토리는 재료 창고(DB)한테
여기서 반대로 요청하는 것은 절대로 있을 수 없다는 것을 기억하자!!
점원이 바로 건너뛰고 요청한다? 불가능
모든게 조직화 직계연결된 것만 가능하다
•
요청 (Request)
점원은 요리사에게 요청하고 요리사는 재료담당 직원에게 요청하는 관계
•
응답 (Recieve)
재료창고로 부터 -> 재료 담당 직원이 살짝 가공해서 요리사에게 주고
그것을 요리사가 점원에게 요리해서 주고 점원은 최종적으로 고객에게 가져다 준다
•
이렇게 나누는 구조로 명언 프로그램이 설계되어 있다
◦
중요한 일은 다 토스-!
◦
요리사와 재료담당직원이 이 프로그램은 합쳐져있다
◦
⇒ 서비스 겸 리포지터리
◦
결과적으로, mvc 패턴을 적용해 소프트웨어 개발을 간단하고 유지 관리가 쉽고 이해하기 쉽도록 설계할 수 있다!
