MVC 접근법

MVC 아키텍처 소개

모든 프로그래머가 알고 있는 가장 인기 있는 애플리케이션 아키텍처는 MVC 입니다 . MVC는 Model-View-Controller 의 약자입니다 .

이것은 애플리케이션 구성 요소의 아키텍처만큼 애플리케이션의 아키텍처가 아니지만 나중에 이 뉘앙스로 돌아갈 것입니다. MVC란 무엇입니까?

MVC 는 각 구성 요소가 독립적으로 수정될 수 있도록 응용 프로그램 데이터와 제어 논리를 세 개의 개별 구성 요소 (모델, 보기 및 컨트롤러 ) 로 분리하는 체계입니다 .

• 모델(Model)은 데이터를 제공하고 상태를 변경하여 컨트롤러 명령에 응답합니다.
• 뷰는 모델 변경에 대한 응답으로 사용자에게 모델 데이터를 표시하는 역할을 합니다.
• 컨트롤러(Controller)는 사용자의 행동을 해석하여 모델에 변경이 필요함을 알립니다.

이 모델은 1978년(!)에 발명되었습니다. 예, 적절한 소프트웨어 아키텍처의 문제는 50년 전에도 관련이 있었습니다. 원본의 다이어그램에서 이 모델을 설명하는 방법은 다음과 같습니다.

이 모델은 데이터베이스에 대한 쿼리, 정확성 확인 등 작업을 위한 데이터 및 방법을 제공합니다. 모델은 뷰 (데이터를 렌더링하는 방법을 알지 못함) 및 컨트롤러(사용자 상호 작용 지점이 없음)와 독립적이며 데이터에 대한 액세스 및 관리를 제공합니다.

모델은 상태를 변경하여 요청에 응답하는 방식으로 구축되며 "관찰자"에 대한 알림이 내장될 수 있습니다. 모델은 시각적 표현과의 독립성으로 인해 하나의 "모델"에 대해 여러 가지 다른 표현을 가질 수 있습니다 .

뷰는 모델에서 필요한 데이터를 가져와 사용자에게 보내는 역할을 합니다. 보기는 사용자 입력을 처리하지 않습니다.

컨트롤러는 사용자와 시스템 간의 "통신"을 제공합니다. 사용자에서 시스템으로 또는 그 반대로 데이터를 제어하고 지시합니다. 모델과 뷰를 사용하여 원하는 작업을 구현합니다.

이 모델이 수십 년에 걸쳐 조금씩 진화했다는 사실에는 특정한 어려움이 있습니다. 즉, 이름은 동일하게 유지되었지만 부품의 목적이 변경되기 시작했습니다.

웹의 MVC 아키텍처

MVC 디자인 패턴의 기본 개념은 매우 간단합니다. 애플리케이션에서 서로 다른 동작에 대한 책임을 명확하게 분리해야 합니다.

모델— 데이터 처리 및 애플리케이션 로직.

보다— 지원되는 모든 형식으로 사용자에게 데이터를 제공합니다.

제어 장치- 사용자 요청을 처리하고 적절한 리소스를 호출합니다.

응용 프로그램은 세 가지 주요 구성 요소로 나뉘며 각 구성 요소는 서로 다른 작업을 담당합니다. 예제를 사용하여 클라이언트-서버 애플리케이션의 구성 요소를 자세히 살펴보겠습니다.

제어 장치

사용자는 브라우저에서 페이지의 다양한 요소를 클릭하고 그 결과 브라우저는 GET, POST 등 다양한 HTTP 요청을 보냅니다. 컨트롤러는 페이지 내에서 작동하는 브라우저 및 JS 코드를 포함할 수 있습니다.

이 경우 컨트롤러의 주요 기능은 필요한 개체에 대한 메서드를 호출하고 리소스에 대한 액세스를 관리하여 사용자가 지정한 작업을 수행하는 것입니다. 일반적으로 컨트롤러는 작업에 적합한 모델을 호출하고 적절한 보기를 선택합니다.

모델

넓은 의미에서 모델은 데이터 작업에 사용되는 데이터 및 규칙이며 함께 애플리케이션의 비즈니스 논리를 구성합니다. 애플리케이션 설계는 항상 애플리케이션이 작동하는 객체의 모델을 구축하는 것으로 시작합니다.

책을 판매하는 온라인 상점이 있다고 가정하면 사람은 응용 프로그램 사용자일 뿐입니까 아니면 책의 저자이기도 합니까? 이러한 중요한 질문은 모델 설계 중에 해결해야 합니다.

또한 규칙 집합이 있습니다. 수행할 수 있는 작업, 수행할 수 없는 작업, 허용되는 데이터 집합 및 허용되지 않는 데이터 집합입니다. 작가 없이 책이 존재할 수 있을까? 그리고 책이없는 저자? 사용자의 생년월일이 300년 등일 수 있습니까?

이 모델은 사용자가 요청한 데이터(메시지, 책 페이지, 사진 등)의 보기를 컨트롤러에 제공합니다. 데이터 모델은 사용자에게 제공하려는 방식에 관계없이 동일합니다. 따라서 데이터를 표시하기 위해 사용 가능한 보기를 선택합니다.

모델에는 우리가 다루고 있는 문제(포럼, 상점, 은행 등)를 해결하는 로직인 애플리케이션 로직의 가장 중요한 부분이 포함되어 있습니다. 컨트롤러에는 대부분 애플리케이션 자체에 대한 조직적 논리가 포함되어 있습니다(프로젝트 관리자와 마찬가지로).

보다

보기는 모델에서 받은 데이터를 나타내는 다양한 방법을 제공합니다. 데이터로 채워진 템플릿이 될 수 있습니다. 여러 보기가 있을 수 있으며 컨트롤러는 현재 상황에 가장 적합한 보기를 선택합니다.

웹 애플리케이션은 일반적으로 컨트롤러, 모델 및 보기 세트로 구성됩니다. 컨트롤러는 백엔드에만 있을 수 있지만 논리가 프런트엔드에도 분산되는 경우 여러 컨트롤러의 변형이 있을 수도 있습니다. 이 접근 방식의 좋은 예는 모든 모바일 애플리케이션입니다.

웹상의 MVC 예제

책을 판매할 온라인 상점을 개발해야 한다고 가정해 보겠습니다. 사용자는 다음 작업을 수행할 수 있습니다. 책 보기, 등록, 구매, 현재 주문에 항목 추가, 좋아하는 책 표시 및 구매.

애플리케이션에는 모든 비즈니스 논리를 담당하는 모델이 있어야 합니다. 또한 모든 사용자 작업을 처리하고 비즈니스 로직에서 메서드 호출로 전환하는 컨트롤러가 필요합니다. 그러나 하나의 컨트롤러 메서드는 여러 다른 모델 메서드를 호출할 수 있습니다.

또한 책 목록, 한 권의 책에 대한 정보, 장바구니, 주문 목록과 같은 일련의 보기가 필요합니다. 웹 애플리케이션의 각 페이지는 실제로 모델의 특정 측면을 사용자에게 표시하는 별도의 보기입니다.

사용자가 제목을 보기 위해 서점 추천 도서 목록을 열면 어떻게 되는지 살펴보겠습니다. 전체 작업 순서는 6단계 형식으로 설명할 수 있습니다.

단계:

1. 사용자가 "권장" 링크를 클릭하면 브라우저가 /books/recommendations로 요청을 보냅니다.
2. 컨트롤러가 요청을 확인합니다 . 사용자는 로그인해야 합니다. 또는 로그인하지 않은 사용자를 위한 책 모음이 있어야 합니다. 그런 다음 컨트롤러는 모델을 호출하고 사용자 N에게 추천된 책 목록을 반환하도록 요청합니다.
3. 모델은 데이터베이스에 액세스하고 거기에서 책에 대한 정보를 검색합니다. 현재 인기 있는 책, 사용자가 구입한 책, 친구가 구입한 책, 위시리스트에 있는 책. 이 데이터를 기반으로 모델은 10권의 추천 도서 목록을 작성하고 컨트롤러에 반환합니다.
4. 컨트롤러는 추천도서 목록을 받아 살펴봅니다. 이 단계에서 컨트롤러가 결정을 내립니다! 책이 거의 없거나 목록이 완전히 비어 있으면 로그인하지 않은 사용자에게 책 목록을 요청합니다. 현재 진행 중인 프로모션이 있는 경우 컨트롤러는 목록에 프로모션 도서를 추가할 수 있습니다.
5. 컨트롤러는 사용자에게 표시할 페이지를 결정합니다. 오류 페이지, 책 목록이 있는 페이지, 사용자가 백만 번째 방문자가 되었음을 축하하는 페이지일 수 있습니다.
6. 서버는 클라이언트에게 컨트롤러가 선택한 페이지( 보기 )를 제공합니다. 필요한 데이터(사용자 이름, 도서 목록)로 채워지고 클라이언트로 이동합니다.
7. 클라이언트는 페이지를 수신하여 사용자에게 표시합니다.

이 접근 방식의 이점은 무엇입니까?

MVC 개념을 사용하여 얻을 수 있는 가장 확실한 이점은 프레젠테이션 논리(사용자 인터페이스)와 응용 프로그램 논리(백엔드)가 명확하게 분리된다는 것입니다.

두 번째 이점은 서버 부분을 스마트 모델( 실행자 )과 컨트롤러( 결정 센터 )의 두 부분으로 나누는 것입니다.

이전 예제에서는 컨트롤러가 모델에서 빈 추천 도서 목록을 수신하고 이를 어떻게 처리할지 결정할 수 있는 순간이 있었습니다. 이론적으로 이 논리는 모델에 직접 입력할 수 있습니다.

첫째, 추천 도서를 요청할 때 모델은 목록이 비어 있는 경우 수행할 작업을 결정합니다. 그런 다음 같은 위치에 코드를 추가하고 지금 진행 중인 프로모션이 있는 경우 수행할 작업과 더 다양한 옵션을 추가해야 합니다.

그런 다음 상점 관리자는 프로모션 없이 사용자 페이지가 어떻게 보이는지 또는 그 반대의 경우 현재 프로모션이 없지만 향후 프로모션이 어떻게 표시되는지 확인하고 싶어했습니다. 그리고 이에 대한 방법이 없습니다. 따라서 비즈니스 로직(모델)에서 의사 결정 센터(컨트롤러)를 분리하기로 결정했습니다.

애플리케이션 로직에서 뷰를 분리하는 것 외에도 MVC 개념은 대규모 애플리케이션의 복잡성을 크게 줄입니다. 코드가 훨씬 더 구조화되어 솔루션을 유지 관리, 테스트 및 재사용하기가 더 쉬워졌습니다.

MVC의 개념을 이해하면 개발자로서 도서 목록 정렬을 추가해야 하는 위치를 알 수 있습니다.

• 데이터베이스 쿼리 수준에서.
• 비즈니스 로직(모델) 수준에서.
• 비즈니스 논리 수준(컨트롤러)에서.
• 보기에서 - 클라이언트 측에서.

그리고 이것은 수사학적 질문이 아닙니다. 지금 바로 책 목록을 정렬하기 위한 코드를 추가해야 하는 위치와 이유에 대해 생각해 보십시오.

클래식 MVC 모델

MVC 구성 요소 간의 상호 작용은 웹 애플리케이션과 모바일 애플리케이션에서 다르게 구현됩니다. 이는 웹 앱이 수명이 짧고 하나의 사용자 요청을 처리하고 종료하는 반면 모바일 앱은 다시 시작하지 않고 많은 요청을 처리하기 때문입니다.

웹 애플리케이션은 일반적으로 "수동" 모델을 사용하고 모바일 애플리케이션은 "활성" 모델을 사용합니다. 능동 모델은 수동 모델과 달리 구독하고 변경 사항에 대한 알림을 받을 수 있습니다. 웹 애플리케이션에는 필요하지 않습니다.

다양한 모델에서 구성 요소의 상호 작용은 다음과 같습니다.

모바일 애플리케이션(활성 모델)은 이벤트 및 이벤트 구독 메커니즘을 적극적으로 사용합니다. 이 접근 방식을 사용하면 뷰( view )가 모델 변경 사항을 구독합니다. 그런 다음 어떤 이벤트가 발생하면(예: 사용자가 버튼을 클릭) 컨트롤러가 호출됩니다 . 또한 모델에 데이터 변경 명령을 제공합니다.

일부 데이터가 변경된 경우 모델은 이 데이터 변경에 대한 이벤트를 생성합니다. 이 이벤트를 구독한 모든 보기(이 특정 데이터를 변경하는 것이 중요함)는 이 이벤트를 수신하고 해당 인터페이스의 데이터를 업데이트합니다.

웹 애플리케이션에서는 상황이 약간 다르게 구성됩니다. 주요 기술적 차이점은 클라이언트가 서버 주도로 서버 측 메시지를 수신할 수 없다는 것입니다 .

따라서 웹 애플리케이션의 컨트롤러는 일반적으로 뷰에 메시지를 보내지 않지만 클라이언트에게 기술적으로 새로운 뷰 또는 새로운 클라이언트 애플리케이션인 새 페이지를 제공합니다(한 페이지가 다른 페이지에 대해 아무것도 모르는 경우). .

현재 이 문제는 다음 접근 방식을 사용하여 부분적으로 해결됩니다.

• 중요한 데이터의 변경 사항에 대해 정기적으로 서버를 폴링합니다(1분에 한 번 이상).
• WebSocket을 사용하면 클라이언트가 서버 메시지를 구독할 수 있습니다.
• 서버 측의 웹 푸시 알림.
• HTTP/2 프로토콜을 사용하면 서버에서 클라이언트로 메시지 전송을 시작할 수 있습니다.