Architecture Pattern

게시 2024/04/09 업데이트 2024/08/29

By Mascari4615

6 분읽는 시간

💫 아키텍처 패턴

서로 다른 시스템과 환경에서 시도되고 테스트된 우수한 사례를 정형화하고 추상화한 기술
이전 시스템에서 성공적이었던 시스템 구조 기술
해당 패턴을 언제 사용하기에 적절하고 적절하지 않은지에 대한 정보 포함
패턴의 강점과 약점에 대한 상세한 내용 포함

💫 MVC

Model, View, Controller의 약자
사용자 인터페이스로부터 비즈니스 로직을 세 가지 파트로 분리하여 서로 영향 없이 개발할 수 있는 설계가 가능

비즈니스 로직 : 사용자가 원하는 기능을 수행하기 위해 필요한 데이터를 처리하는 로직 (Input 받고, Process 하고, Output 내보내기)

Model : DB와 연동하여 데이터를 처리하는 부분
View : 사용자에게 보여지는 부분
- 회원가입 버튼, 로그인 버튼
Controller : 사용자의 입력을 받아 처리하는 부분
- View에서 버튼을 누르면, Controller가 요청을 받아서 처리

🫧 Model

데이터를 처리하는 영역
데이터베이스와 연동을 위한 DAO(Data Access Object)와 데이터의 구조를 표현하는 DO (Data Object)로 구성됨

i.e. 검색을 위한 키워드가 넘어오면 DB에서 관련된 상품의 데이터를 받아 뷰에 전달

🫧 View

데이터를 보여주는 화면 자체의 영역을 뜻함
사용자 인터페이스(UI) 요소들이 여기에 포함되며, 데이터를 각 요소에 배치함
뷰에서는 별도의 데이터를 보관하지 않음

i.e.검색 결과를 보여주기 위해 모델에서 결과 상품 리스트 데이터를 받음

🫧 Controller

모델(Model)과 뷰(View) 사이에서 브릿지 역할을 수행
앱의 사용자로부터 입력에 대한 응답으로 모델 및 뷰를 업데이트하는 로직을 포함
사용자의 요청은 모두 Controller로 들어온다. (진행해야 한다.)
컨트롤러로 들어온 요청은 어떻게 처리할지 결정하여 모델로 요청을 전달함

i.e. 쇼핑몰에서 상품을 검색하면 그 키워드를 받아서 입력을 처리하여 모델과 뷰에 적절하게 전달

💫 Layered Architecture

MVC 패턴과 비슷한 이야기, 다만 레이어(계층) 기준으로 설명
유사 관심사를 레이어로 묶어 수평적으로 분리한 구조

일반적으로 3계층 또는 4계층으로 구성됨
프로젝트에 따라 커스터마이징해서 사용

🫧 Presentation

사용자 인터페이스를 제공하는 계층
사용자가 요청을 보냄

🫧 Business

비즈니스 로직을 처리하는 계층
사용자의 요청을 처리하고, 데이터를 처리하는 계층

🫧 Data (Access)

데이터베이스와 연동하는 계층

🫧 U_설명

서브 시스템의 인터페이스를 모델링하는데 이용
각 층이 서비스 집합을 제공하는 계층 집합(추상 머신)으로 시스템을 구성
상이한 계층에 있는 서브 시스템의 점증적 개발을 지원. 계층 인터페이스가 변경될 때, 인접 계층에만 영향을 줌.

🫧 U_장점

시스템의 점증적인 개발을 지원한다. 한 계층이 개발됨에 따라, 그 계층에 의해 제공되는 서비스들의 일부를 사용자가 이용할 수 있다.
변경 가능하며 이식 가능하다. 계층의 인터페이스가 변경되지 않는 한, 동등한 다른 계층에 의해 대체될 수 있다.

🫧 U_단점

시스템을 구조화하는 것이 어려울 수 있다. 최상위 수준의 사용자가 요구하는 서비스는 그 아래의 여러 계층이 제공하는 서비스에 접근하기 위해 인접 계층을 ‘뚫고 지나가야’ 할 수도 있다. 이런 방식은 시스템의 외부 계층이 바로 그 이전의 계층에 종속되지 않음에 따라 계층 모델을 망가뜨리게 된다.
여러 수준의 명령어 해석이 필요하기 때문에 성능이 문제가 될 수 있다. 최상위 계층으로부터의 서비스 요청은 처리되기 전에 상이한 계층에서 여러 번 해석되어야 한다.

💫Computer, 🌒Programming