이 기사에서 우리는 MVC라는 것을 알게 될 것입니다. MVC가 무엇인지에 대해 이야기하고, 그 역사를 접하고, MVC에 구현된 기본 아이디어와 개념을 탐색하고, 애플리케이션을 모델, 뷰 및 컨트롤러 모듈로 나누는 방법을 단계별로 살펴보고, Spring Boot를 사용하는 작은 웹 애플리케이션과 Spring MVC를 예로 사용하여 데이터가 Java 코드에서 HTML 페이지로 전송되는 방식을 확인합니다. 이 자료를 이해하려면 디자인 패턴, 특히 옵저버와 파사드에 익숙해야 합니다. 또한 HTTP 요청 및 응답에 익숙하고 HTML의 기본 사항을 이해하고 Java 주석이 무엇인지 알아야 합니다. 커피 한 잔과 간식을 들고 편안하게 쉬십시오. 의 시작하자.
MVC의 역사
MVC의 기본 아이디어는 1970년대 후반 Xerox PARC에서 근무하는 동안 Trygve Reenskaug가 공식화했습니다. 그 당시 컴퓨터로 작업하려면 방대한 문서에 대한 학위와 지속적인 연구가 필요했습니다. Reenskaug가 강력한 개발자 그룹과 함께 해결한 작업은 일반 사용자와 컴퓨터의 상호 작용을 단순화하는 것이었습니다. 한편으로는 매우 간단하고 이해하기 쉬우면서도 다른 한편으로는 컴퓨터와 복잡한 응용 프로그램을 제어할 수 있는 도구를 만드는 것이 필요했습니다. Reenskaug는 "모든 연령대의 어린이를 위한" 랩톱 컴퓨터인 Dynabook과 Alan Kay의 지도 하에 SmallTalk 언어를 개발한 팀에서 일했습니다. 그것은 친근한 인터페이스의 개념이 정립된 때였습니다. 여러 측면에서 Reenskaug와 그의 팀이 수행한 작업은 IT 영역의 발전에 영향을 미쳤습니다. 다음은 MVC에 직접 적용되지는 않지만 이러한 개발의 중요성을 보여주는 흥미로운 사실입니다. 앨런 케이말했다, "1984년에 Apple에 처음 왔을 때 Mac은 이미 출시된 상태였고 Newsweek에서 제게 연락하여 Mac에 대해 어떻게 생각하는지 물었습니다. 비판을 받아라.' 그래서 2007년에 아이폰을 발표하고 나서 가지고 와서 건네주면서 '앨런, 이거 욕먹을 만큼 좋은거야?' 그리고 나는 '스티브, 태블릿만큼 크게 만들면 세상을 지배하게 될거야'라고 말했습니다." 3년 후인 2010년 1월 27일 애플은 대각선 9.7인치의 아이패드를 선보였습니다. 즉, Steve Jobs는 Alan Kay의 조언을 거의 그대로 따랐습니다. Reenskaug의 프로젝트는 10년 동안 지속되었습니다. 그러나 MVC에 대한 첫 번째 출판물은 10년 후에 밝혀졌습니다. 소프트웨어 아키텍처에 관한 여러 책과 기사의 저자인 Martin Fowler는 작동 중인 Smalltalk 버전을 사용하여 MVC를 연구했다고 언급합니다. 오랜 시간 동안 원본 소스에서 MVC에 대한 정보가 없었기 때문에 여러 가지 다른 이유로 이 개념에 대한 많은 다른 해석이 나타났습니다. 결과적으로 많은 사람들이 MVC를 디자인 패턴으로 간주합니다. 덜 일반적으로 MVC는 복합 패턴 또는 복잡한 애플리케이션을 만들기 위해 함께 작동하는 여러 패턴의 조합이라고 합니다. 그러나 앞에서 언급했듯이 MVC는 실제로 기본적으로 다양한 패턴을 사용하여 다양한 방식으로 구현할 수 있는 일련의 아키텍처 아이디어/원칙/접근 방식입니다. 다음으로 MVC 개념에 포함된 주요 아이디어를 살펴보겠습니다. 그리고 몇 가지 다른 이유로 이 개념에 대한 많은 다른 해석이 나타났습니다. 결과적으로 많은 사람들이 MVC를 디자인 패턴으로 간주합니다. 덜 일반적으로 MVC는 복합 패턴 또는 복잡한 애플리케이션을 만들기 위해 함께 작동하는 여러 패턴의 조합이라고 합니다. 그러나 앞에서 언급했듯이 MVC는 실제로 기본적으로 다양한 패턴을 사용하여 다양한 방식으로 구현할 수 있는 일련의 아키텍처 아이디어/원칙/접근 방식입니다. 다음으로 MVC 개념에 포함된 주요 아이디어를 살펴보겠습니다. 그리고 몇 가지 다른 이유로 이 개념에 대한 많은 다른 해석이 나타났습니다. 결과적으로 많은 사람들이 MVC를 디자인 패턴으로 간주합니다. 덜 일반적으로 MVC는 복합 패턴 또는 복잡한 애플리케이션을 만들기 위해 함께 작동하는 여러 패턴의 조합이라고 합니다. 그러나 앞에서 언급했듯이 MVC는 실제로 기본적으로 다양한 패턴을 사용하여 다양한 방식으로 구현할 수 있는 일련의 아키텍처 아이디어/원칙/접근 방식입니다. 다음으로 MVC 개념에 포함된 주요 아이디어를 살펴보겠습니다.
MVC: 기본 아이디어 및 원칙
VC는 사용자 인터페이스로 복잡한 정보 시스템을 구축하기 위한 일련의 아키텍처 아이디어 및 원칙입니다.
MVC는 Model-View-Controller의 약자입니다.
고지 사항: MVC는 디자인 패턴이 아닙니다. MVC는 사용자 인터페이스로 복잡한 시스템을 구축하기 위한 일련의 아키텍처 아이디어 및 원칙 입니다. 그러나 편의를 위해 반복적으로 "일련의 아키텍처 아이디어..."라고 말하지 않기 위해 MVC 패턴을 참조하겠습니다. 간단한 것부터 시작합시다. Model-View-Controller라는 단어 뒤에 숨겨진 것은 무엇입니까? MVC 패턴을 사용하여 사용자 인터페이스가 있는 시스템을 개발할 때 시스템을 세 가지 구성 요소로 나눌 필요가 있습니다. 모듈 또는 구성 요소라고도 합니다. 원하는대로 부르되 시스템을 세 가지 구성 요소로 나눕니다. 각 구성 요소에는 고유한 용도가 있습니다. 모델. 첫 번째 구성 요소/모듈을 모델이라고 합니다. 여기에는 모든 애플리케이션의 비즈니스 로직이 포함됩니다. 보다.시스템의 두 번째 부분은 보기입니다. 이 모듈은 사용자에게 데이터를 표시하는 역할을 합니다. 사용자가 보는 모든 것은 뷰에 의해 생성됩니다. 제어 장치.이 체인의 세 번째 링크는 컨트롤러입니다. 여기에는 사용자 작업 처리를 담당하는 코드가 포함되어 있습니다(모든 사용자 작업은 컨트롤러에서 처리됨). 모델은 시스템에서 가장 독립적인 부분입니다. 너무 독립적이어서 뷰와 컨트롤러 모듈에 대해 아무것도 몰라야 합니다. 이 모델은 매우 독립적이어서 개발자가 뷰와 컨트롤러에 대해 거의 알지 못할 수도 있습니다. 뷰의 주요 목적은 사용자가 사용할 수 있는 형식으로 모델의 정보를 제공하는 것입니다. 뷰의 주요 제한 사항은 어떤 식으로든 모델을 변경해서는 안 된다는 것입니다. 컨트롤러의 주요 목적은 사용자 작업을 처리하는 것입니다. 사용자가 모델을 변경하는 것은 컨트롤러를 통해서입니다. 또는 더 정확하게는 모델에 저장된 데이터입니다. 다음은 이전 강의에서 본 다이어그램입니다. 이 모든 것으로부터 우리는 논리적 결론을 도출할 수 있습니다. 복잡한 시스템은 모듈로 나누어야 합니다. 이 분리를 달성하는 단계를 간략하게 설명하겠습니다.
1단계. 사용자 인터페이스에서 애플리케이션의 비즈니스 로직 분리
MVC의 주요 아이디어는 사용자 인터페이스가 있는 모든 응용 프로그램을 비즈니스 로직 구현을 담당하는 모듈과 사용자 인터페이스의 두 가지 모듈로 나눌 수 있다는 것입니다. 첫 번째 모듈은 애플리케이션의 주요 기능을 구현합니다. 이 모듈은 애플리케이션의 도메인 모델이 구현되는 시스템의 핵심입니다. MVC 패러다임에서 이 모듈은 문자 M, 즉 모델입니다. 두 번째 모듈은 사용자에게 데이터를 표시하고 응용 프로그램과 사용자 상호 작용을 처리하는 논리를 포함하여 전체 사용자 인터페이스를 구현합니다. 이러한 분리의 주요 목표는 시스템의 핵심(MVC 용어로 "모델")을 독립적으로 개발하고 테스트할 수 있도록 하는 것입니다. 이렇게 분리한 후 애플리케이션의 아키텍처는 다음과 같습니다.
2단계 옵저버 패턴을 사용하여 모델을 더욱 독립적으로 만들고 사용자 인터페이스를 동기화합니다.
여기에는 2가지 목표가 있습니다.
모델에 대해 훨씬 더 큰 독립성 달성
사용자 인터페이스 동기화
다음 예는 사용자 인터페이스 동기화가 의미하는 바를 이해하는 데 도움이 됩니다. 온라인으로 영화 티켓을 구매하고 극장에서 사용 가능한 좌석 수를 확인한다고 가정합니다. 동시에 다른 사람이 영화 표를 구매할 수 있습니다. 다른 사람이 우리보다 먼저 티켓을 구매한다면 우리가 고려하고 있는 상영 시간에 사용 가능한 좌석 수가 줄어들기를 바랍니다. 이제 이것이 프로그램 내에서 어떻게 구현될 수 있는지 생각해 봅시다. 시스템의 핵심(모델)과 인터페이스(티켓 구매를 위한 웹 페이지)가 있다고 가정합니다. 두 명의 사용자가 극장에서 동시에 좌석을 선택하려고 합니다. 첫 번째 사용자가 티켓을 구매합니다. 웹 페이지는 이것이 발생했음을 두 번째 사용자에게 표시해야 합니다. 어떻게 이런 일이 일어날까요? 코어에서 인터페이스를 업데이트하면 그러면 핵심(우리 모델)이 인터페이스에 종속됩니다. 모델을 개발하고 테스트하면서 인터페이스를 업데이트하는 다양한 방법을 염두에 두어야 합니다. 이를 위해서는 옵저버 패턴을 구현해야 합니다. 이 패턴을 사용하면 모델이 모든 수신기에 변경 알림을 보낼 수 있습니다. 이벤트 리스너(또는 관찰자)로서 사용자 인터페이스는 알림을 받고 업데이트됩니다. 한편으로 옵저버 패턴은 모델이 인터페이스(뷰 및 컨트롤러)에 변경 사항이 실제로 알지 못하는 상태에서 발생했음을 알리므로 독립적으로 유지됩니다. 반면에 사용자 인터페이스를 동기화할 수 있습니다. 관찰자 패턴을 구현해야 합니다. 이 패턴을 사용하면 모델이 모든 수신기에 변경 알림을 보낼 수 있습니다. 이벤트 리스너(또는 관찰자)로서 사용자 인터페이스는 알림을 받고 업데이트됩니다. 한편으로 옵저버 패턴은 모델이 인터페이스(뷰 및 컨트롤러)에 변경 사항이 실제로 알지 못하는 상태에서 발생했음을 알리므로 독립적으로 유지됩니다. 반면에 사용자 인터페이스를 동기화할 수 있습니다. 관찰자 패턴을 구현해야 합니다. 이 패턴을 사용하면 모델이 모든 수신기에 변경 알림을 보낼 수 있습니다. 이벤트 리스너(또는 관찰자)로서 사용자 인터페이스는 알림을 받고 업데이트됩니다. 한편으로 옵저버 패턴은 모델이 인터페이스(뷰 및 컨트롤러)에 변경 사항이 실제로 알지 못하는 상태에서 발생했음을 알리므로 독립적으로 유지됩니다. 반면에 사용자 인터페이스를 동기화할 수 있습니다.
3단계 인터페이스를 뷰와 컨트롤러로 분리
애플리케이션을 모듈로 계속 나누지만 이제 계층 구조의 하위 수준에 있습니다. 이 단계에서 사용자 인터페이스(1단계에서 별개의 모듈로 분리)는 뷰와 컨트롤러로 분할됩니다. 뷰와 컨트롤러 사이에 엄격한 선을 긋는 것은 어렵습니다. 뷰는 사용자가 보는 것이고 컨트롤러는 사용자가 시스템과 상호 작용할 수 있게 해주는 메커니즘이라고 하면 모순을 지적할 수 있습니다. 웹 페이지의 버튼이나 전화기 화면의 가상 키보드와 같은 제어 요소는 기본적으로 컨트롤러의 일부입니다. 그러나 보기의 일부로 사용자에게 표시됩니다. 여기서 우리가 실제로 이야기하고 있는 것은 기능적 분리입니다. 사용자 인터페이스의 주요 작업은 사용자와 시스템의 상호 작용을 용이하게 하는 것입니다.
시스템 정보를 출력하여 사용자에게 편리하게 표시
사용자 데이터 및 명령 입력(시스템에 전달)
이러한 함수는 사용자 인터페이스를 모듈로 나누는 방법을 결정합니다. 결국 시스템 아키텍처는 다음과 같습니다. 그리고 이것이 모델, 뷰 및 컨트롤러라는 세 가지 모듈로 구성된 애플리케이션에 도달하는 방법입니다. 요약하자면:
MVC 패러다임의 원칙에 따라 시스템은 모듈로 나누어져야 합니다.
가장 중요하고 독립적인 모듈은 모델이어야 합니다.
모델은 시스템의 핵심입니다. 사용자 인터페이스와 독립적으로 개발하고 테스트할 수 있어야 합니다.
이를 위해서는 분할의 첫 단계에서 시스템을 모델과 사용자 인터페이스로 분할해야 합니다.
그런 다음 관찰자 패턴을 사용하여 모델의 독립성을 강화하고 사용자 인터페이스를 동기화합니다.
세 번째 단계는 사용자 인터페이스를 컨트롤러와 뷰로 나누는 것입니다.
사용자 데이터를 시스템으로 수신하는 데 필요한 모든 것이 컨트롤러에 있습니다.
사용자에게 정보를 전달하는 데 필요한 모든 것이 보기에 있습니다.
핫 초콜릿을 마시기 전에 논의해야 할 중요한 사항이 하나 더 있습니다.
뷰와 컨트롤러가 모델과 상호 작용하는 방법에 대해 조금
컨트롤러를 통해 정보를 입력하면 사용자가 모델을 변경합니다. 또는 최소한 사용자가 모델 데이터를 변경합니다. 사용자가 인터페이스 요소(뷰를 통해)를 통해 정보를 수신하면 사용자는 모델에 대한 정보를 수신합니다. 어떻게 이런 일이 발생합니까? 뷰와 컨트롤러는 어떤 방식으로 모델과 상호 작용합니까? 결국, 뷰의 클래스는 데이터를 읽고 쓰기 위해 모델 클래스의 메서드를 직접 호출할 수 없습니다. 그렇지 않으면 모델이 독립적이라고 말할 수 없습니다. 모델은 뷰나 컨트롤러가 액세스할 수 없는 밀접하게 관련된 클래스 집합입니다. 모델을 뷰와 컨트롤러에 연결하려면 파사드 디자인 패턴을 구현해야 합니다. 모델의 파사드는 모델과 사용자 인터페이스 사이의 레이어입니다. 이를 통해 뷰는 편리한 형식의 데이터를 수신하고 컨트롤러는 파사드에서 필요한 메소드를 호출하여 데이터를 변경합니다. 결국 모든 것이 다음과 같이 보입니다.
MVC: 우리는 무엇을 얻습니까?
MVC 패러다임의 주요 목표는 비즈니스 로직(모델)의 구현을 시각화(뷰)에서 분리하는 것입니다. 이러한 분리는 코드 재사용 가능성을 높입니다. MVC의 이점은 동일한 데이터를 다른 형식으로 표시해야 할 때 가장 분명합니다. 예를 들어 테이블, 그래프 또는 차트(다른 보기 사용). 동시에 뷰가 구현되는 방식에 영향을 주지 않고 사용자 작업(버튼 클릭, 데이터 입력)에 응답하는 방식을 변경할 수 있습니다. MVC의 원칙을 따르면 소프트웨어 개발을 단순화하고 코드 가독성을 높이며 확장성과 유지 관리성을 향상시킬 수 있습니다. "엔터프라이즈 개발 소개" 시리즈의 마지막 기사에서는 Spring MVC를 사용하여 구축된 MVC 구현을 살펴볼 것입니다. Part 8. Spring Boot를 사용하여 작은 애플리케이션을 작성해 봅시다.
이 기사에서 우리는 MVC라는 것을 알게 될 것입니다. MVC가 무엇인지에 대해 이야기하고, 그 역사를 접하고, MVC에 구현된 기본 아이디어와 개념을 탐색하고, 애플리케이션을 모델, 뷰 및 컨트롤러 모듈로 나누는 방법을 단계별로 살펴보고, Spring Boot를 사용하는 작은 웹 애플리케이션과 Spring MVC를 예로 사용하여 데이터가 Java 코드에서 HTML 페이지로 전송되는 방식을 확인합니다. 이 자료를 이해하려면 디자인 패턴, 특히 옵저버와 파사드에 익숙해야 합니다. 또한 HTTP 요청 및 응답에 익숙하고 HTML의 기본 사항을 이해하고 Java 주석이 무엇인지 알아야 합니다. 커피 한 잔과 간식을 들고 편안하게 쉬십시오. 의 시작하자.
이 모든 것으로부터 우리는 논리적 결론을 도출할 수 있습니다. 복잡한 시스템은 모듈로 나누어야 합니다. 이 분리를 달성하는 단계를 간략하게 설명하겠습니다.
그리고 이것이 모델, 뷰 및 컨트롤러라는 세 가지 모듈로 구성된 애플리케이션에 도달하는 방법입니다. 요약하자면:
