JavaRush /Java Blog /Random-KO /7부. MVC(Model-View-Controller) 패턴 소개

7부. MVC(Model-View-Controller) 패턴 소개

Random-KO 그룹에 게시되었습니다
이 자료는 "엔터프라이즈 개발 소개" 시리즈의 일부입니다. 이전 기사: 7부. MVC(Model-View-Controller) 패턴 소개 - 1이 자료에서는 MVC와 같은 것을 소개합니다. MVC가 무엇인지 이야기하고, MVC 생성의 역사를 다루고, MVC에 내재된 주요 아이디어와 개념을 이해하고, 애플리케이션을 모델, 뷰, 컨트롤러 모듈로 나누는 방법을 단계별로 고려하고, 작은 웹 애플리케이션을 작성하는 방법도 살펴보겠습니다. Spring-Boot 및 Spring-MVC를 예로 들어 Java 코드에서 html 페이지로 데이터가 전송되는 방법을 살펴보겠습니다. 이 자료를 이해하려면 디자인 패턴, 특히 Observer 및 Facade에 대해 잘 알고 있어야 합니다. HTTP 요청 및 응답에 익숙해지고, HTML의 기본 사항을 이해하고, Java에 어떤 주석이 있는지 알아보세요. 편안히 앉아 차를 만들고, 디저트, 샐러드, 메인 코스와 첫 번째 코스를 준비하세요. 우리는 시작합니다.

MVC의 역사

MVC에 대한 아이디어는 70년대 후반 Xerox PARC에서 근무하면서 Trygve Reenskaug가 고안했습니다. 그 당시 컴퓨터 작업은 학업 학위와 방대한 문서에 대한 끊임없는 연구 없이는 불가능했습니다. Reenskaug가 매우 강력한 개발자 그룹과 함께 해결한 문제는 일반 사용자와 컴퓨터의 상호 작용을 단순화하는 것이었습니다. 한편으로는 매우 간단하고 이해하기 쉬우면서도 다른 한편으로는 컴퓨터와 복잡한 애플리케이션을 관리할 수 있는 도구를 만드는 것이 필요했습니다. Reenskaug는 Alan Kay의 지도 하에 "모든 연령대의 어린이를 위한" 휴대용 컴퓨터인 Dynabook과 SmallTalk 언어를 개발하는 팀에서 일했습니다. 친숙한 인터페이스의 개념이 확립된 것은 바로 그때였습니다. Reenskaug와 그의 팀의 작업은 IT 분야의 발전에 큰 영향을 미쳤습니다. MVC와 직접적으로 관련되지는 않지만 이러한 개발의 중요성을 보여주는 흥미로운 사실을 제시하겠습니다. 2007년, Apple iPhone이 발표된 후 Alan Kay는 다음과 같이 말했습니다. “Macintosh가 나왔을 때 Newsweek는 나에게 그것에 대해 어떻게 생각하는지 물었습니다. 나는 이렇게 말했습니다. 이것은 비판받을 만한 최초의 개인용 컴퓨터입니다. 프레젠테이션이 끝난 후 Steve Jobs가 와서 물었습니다. iPhone이 비판받을 가치가 있습니까? 그리고 저는 가로세로 5인치, 세로 8인치로 만들면 세계를 정복할 것이라고 말했습니다.” 3년 후인 2010년 1월 27일, Apple은 9.7인치 iPad를 출시했습니다. 즉, 스티브 잡스는 Alan Kay의 조언을 거의 문자 그대로 따랐습니다. Rennskaug가 작업한 프로젝트는 10년 동안 지속되었습니다. 그리고 제작자가 MVC에 관한 첫 번째 출판물을 10년 후에 출판했습니다. 소프트웨어 아키텍처에 관한 여러 책과 기사의 저자인 Martin Fowler는 SmallTalk의 작동 버전에서 MVC를 배웠다고 언급합니다. 오랫동안 기본 소스로부터 MVC에 대한 정보가 없었고 다른 여러 가지 이유로 인해 이 개념에 대한 다양한 해석이 나타났습니다. 결과적으로 많은 사람들은 MVC를 디자인 체계나 패턴으로 간주합니다. 덜 일반적으로 MVC는 복합 패턴 또는 복잡한 애플리케이션을 구현하기 위해 함께 작동하는 여러 패턴의 조합이라고 합니다. 하지만 사실 앞서 말했듯이 MVC는 기본적으로 다양한 패턴을 사용하여 다양한 방식으로 구현할 수 있는 일련의 아키텍처 아이디어/원리/접근 방식입니다... 다음으로 MVC 개념에 포함된 주요 아이디어를 살펴보겠습니다.

MVC란 무엇인가: 기본 아이디어와 원리

  • VC는 사용자 인터페이스를 갖춘 복잡한 정보 시스템을 구축하기 위한 일련의 아키텍처 아이디어와 원칙입니다.
  • MVC는 Model-View-Controller의 약어입니다.
면책조항: MVC는 디자인 패턴이 아닙니다. MVC는 사용자 인터페이스를 사용하여 복잡한 시스템을 구축하기 위한 아키텍처 아이디어와 원칙의 집합 입니다. 그러나 편의상 매번 반복하지 않기 위해 "아키텍처 아이디어 세트..."를 MVC라고 부르겠습니다. 간단한 것부터 시작해 보겠습니다. Model-View-Controller라는 단어 뒤에 무엇이 숨겨져 있습니까? 사용자 인터페이스가 있는 시스템을 개발할 때 MVC 패턴에 따라 시스템을 세 가지 구성 요소로 나누어야 합니다. 이를 모듈 또는 구성요소라고 부를 수 있습니다. 원하는 것을 말하되 3으로 나누세요. 각 구성 요소에는 고유한 목적이 있습니다. 모델. 첫 번째 구성 요소/모듈은 소위 모델입니다. 여기에는 애플리케이션의 모든 비즈니스 로직이 포함됩니다. 보다. 시스템의 두 번째 부분은 뷰입니다. 이 모듈은 사용자에게 데이터를 표시하는 역할을 담당합니다. 사용자가 보는 모든 것은 뷰에 의해 생성됩니다. 제어 장치. 이 체인의 세 번째 링크는 컨트롤러입니다. 사용자 작업 처리를 담당하는 코드를 저장합니다(시스템의 모든 사용자 작업은 컨트롤러에서 처리됨). 모델은 시스템에서 가장 독립적인 부분입니다. 매우 독립적이어서 뷰 및 컨트롤러 모듈에 대해 아무것도 몰라야 합니다. 모델은 매우 독립적이므로 개발자는 뷰와 컨트롤러에 대해 사실상 아무것도 알지 못할 수 있습니다. 뷰의 주요 목적은 모델의 정보를 사용자에게 친숙한 형식으로 제공하는 것입니다. 뷰의 주요 제한 사항은 어떤 방식으로든 모델을 변경해서는 안 된다는 것입니다. 컨트롤러의 주요 목적은 사용자 작업을 처리하는 것입니다. 사용자가 모델을 변경하는 것은 컨트롤러를 통해서입니다. 보다 정확하게는 모델에 저장된 데이터입니다. 강의에서 이미 보여드린 다이어그램을 다시 살펴보겠습니다. 7부. MVC(Model-View-Controller) 패턴 소개 - 2이 모든 것에서 우리는 완전히 논리적인 결론을 도출할 수 있습니다. 복잡한 시스템은 모듈로 나누어야 합니다. 그러한 분리를 달성하는 방법에 대한 단계를 간략하게 설명하겠습니다.

1단계: 애플리케이션의 비즈니스 로직을 사용자 인터페이스에서 분리

MVC의 핵심 아이디어는 사용자 인터페이스가 있는 모든 애플리케이션이 대략적으로 2개의 모듈, 즉 애플리케이션의 비즈니스 로직 구현을 담당하는 모듈과 사용자 인터페이스로 나눌 수 있다는 것입니다. 첫 번째 모듈은 애플리케이션의 주요 기능을 구현합니다. 이 모듈은 애플리케이션 도메인 모델이 구현되는 시스템의 핵심이 됩니다. MVC 개념에서 이 모듈은 문자 M이 됩니다. 모델. 두 번째 모듈은 사용자에게 데이터 표시 및 사용자와 애플리케이션의 상호 작용 논리를 포함하여 전체 사용자 인터페이스를 구현합니다. 이러한 분리의 주요 목적은 시스템의 핵심(MVC 용어로 모델)을 독립적으로 개발하고 테스트할 수 있도록 하는 것입니다. 이러한 분할 후의 애플리케이션 아키텍처는 다음과 같습니다. 7부. MVC(Model-View-Controller) 패턴 소개 - 3

2단계. 관찰자 패턴을 사용하여 모델의 독립성과 사용자 인터페이스의 동기화를 더욱 강화합니다.

여기서 우리는 2가지 목표를 추구합니다:
  1. 모델의 독립성을 더욱 향상시킵니다.
  2. 사용자 인터페이스를 동기화합니다.
다음 예는 사용자 인터페이스 동기화의 의미를 이해하는 데 도움이 됩니다. 온라인으로 영화표를 구매하고 극장에서 사용 가능한 좌석 수를 확인한다고 가정해 보겠습니다. 다른 사람도 우리와 동시에 영화표를 구입할 수 있습니다. 이 사람이 우리보다 먼저 티켓을 구매한다면 우리 세션에 사용 가능한 좌석 수가 감소했는지 확인하고 싶습니다. 이제 이것이 프로그램 내에서 어떻게 구현될 수 있는지 생각해 봅시다. 시스템 코어(모델)와 인터페이스(구매하는 웹 페이지)가 있다고 가정해 보겠습니다. 사이트에서는 2명의 사용자가 동시에 좌석을 선택합니다. 첫 번째 사용자가 티켓을 구매했습니다. 두 번째 사용자는 이 정보를 페이지에 표시해야 합니다. 어떻게 이런 일이 일어나야 합니까? 시스템 커널에서 인터페이스를 업데이트하면 커널, 즉 모델이 인터페이스에 종속됩니다. 모델을 개발하고 테스트할 때 인터페이스를 업데이트하는 다양한 방법을 염두에 두어야 합니다. 이를 위해서는 Observer 패턴을 구현해야 합니다. 도움을 받아 모델은 모든 구독자에게 변경 사항에 대한 알림을 보냅니다. 그러한 구독자인 인터페이스는 알림과 업데이트를 받게 됩니다. 관찰자 패턴을 사용하면 모델은 한편으로는 변경 사항이 발생했음을 인터페이스(뷰 및 컨트롤러)에 알리고 다른 한편으로는 실제로는 아무것도 "알지" 못하므로 독립적인 상태를 유지할 수 있습니다. 반면에 이를 통해 사용자 인터페이스를 동기화할 수 있습니다.

Step 3. 인터페이스를 View와 Controller로 나누기

우리는 계속해서 애플리케이션을 모듈로 나누지만 계층 구조의 낮은 수준에 있습니다. 이 단계에서는 1단계에서 별도의 모듈로 분리된 사용자 인터페이스를 뷰와 컨트롤러로 구분합니다. 뷰와 컨트롤러 사이에 엄격한 선을 긋는 것은 어렵습니다. 뷰는 사용자가 보는 것이고 컨트롤러는 사용자가 시스템과 상호 작용할 수 있는 메커니즘이라고 말하면 모순이 있습니다. 웹 페이지의 버튼이나 전화기 화면의 가상 키보드와 같은 컨트롤은 기본적으로 컨트롤러의 일부입니다. 그러나 뷰의 다른 부분과 마찬가지로 사용자에게 표시됩니다. 여기서는 기능적 분할에 대해 자세히 설명합니다. 사용자 인터페이스의 주요 임무는 사용자와 시스템의 상호 작용을 보장하는 것입니다. 즉, 인터페이스에는 2가지 기능만 있습니다.
  • 시스템에 관한 정보를 사용자에게 표시하고 편리하게 표시합니다.
  • 사용자 데이터와 명령을 시스템에 입력합니다(시스템으로 전송).
이러한 기능은 인터페이스를 모듈로 나누는 방법을 결정합니다. 결과적으로 시스템 아키텍처는 다음과 같습니다. 7부. MVC(Model-View-Controller) 패턴 소개 - 4따라서 모델, 뷰 및 컨트롤러라는 세 가지 모듈의 애플리케이션이 있습니다. 요약:
  1. MVC의 원칙에 따라 시스템을 모듈로 나누어야 합니다.
  2. 가장 중요하고 독립적인 모듈은 모델이어야 합니다.
  3. 모델은 시스템의 핵심이다. 인터페이스와 독립적으로 개발하고 테스트할 수 있는 능력이 필요합니다.
  4. 이를 위해서는 시스템 분리의 첫 번째 단계에서 모델과 인터페이스로 나누어야 합니다.
  5. 다음으로 Observer 패턴을 사용하여 모델의 독립성을 강화하고 사용자 인터페이스의 동기화를 얻습니다.
  6. 세 번째 단계는 인터페이스를 컨트롤러와 뷰로 나누는 것입니다.
  7. 사용자의 정보를 시스템에 입력하는 데 필요한 모든 것은 컨트롤러에 있습니다.
  8. 시스템에서 사용자에게 정보를 출력하는 모든 정보가 표시됩니다.
논의해야 할 중요한 일이 하나 더 남았으며 코코아를 마실 수 있습니다.

뷰와 컨트롤러, 모델의 관계에 대해 조금

사용자가 컨트롤러를 통해 정보를 입력하면 모델이 변경됩니다. 최소한 사용자는 모델 데이터를 변경합니다. 사용자가 인터페이스 요소(View를 통해)를 통해 정보를 받으면 모델 데이터에 대한 정보를 받게 됩니다. 어떻게 이런 일이 발생하나요? 뷰와 컨트롤러는 모델과 어떻게 상호작용하나요? 결국, View 클래스가 Model 클래스의 메서드를 직접 사용하여 데이터를 읽고 쓸 수는 없습니다. 그렇지 않으면 모델의 독립성에 의문의 여지가 없습니다. 모델은 뷰나 컨트롤러 모두 접근할 수 없는 긴밀하게 상호 연결된 클래스 집합을 나타냅니다. Model을 View, Controller와 연결하기 위해서는 Facade 디자인 패턴을 구현해야 합니다. 모델 파사드는 모델과 인터페이스 사이의 바로 그 레이어가 될 것이며, 이를 통해 뷰는 편리한 형식으로 데이터를 수신하고 컨트롤러는 필요한 파사드 메소드를 호출하여 데이터를 변경합니다. 개략적으로 보면 모든 것이 다음과 같이 보일 것입니다. 7부. MVC(Model-View-Controller) 패턴 소개 - 6

MVC: 이점은 무엇입니까?

MVC 원칙을 따르는 주요 목표는 애플리케이션의 비즈니스 로직(모델) 구현과 시각화(뷰)를 분리하는 것입니다. 이렇게 분리하면 코드 재사용이 늘어납니다. MVC 사용의 이점은 사용자가 동일한 데이터를 다른 형식으로 제공해야 하는 경우 가장 분명합니다. 예를 들어, 표, 그래프 또는 차트 형식(다양한 유형 사용)입니다. 동시에 뷰 구현에 영향을 주지 않고 사용자 작업(버튼 클릭, 데이터 입력)에 대한 반응을 변경할 수 있습니다. MVC의 원칙을 따르면 프로그램 작성을 단순화하고 코드의 가독성을 높이며 향후 시스템 확장 및 유지 관리를 더 쉽게 할 수 있습니다. "엔터프라이즈 개발 입문" 시리즈의 마지막 자료에서는 Spring-MVC를 예로 들어 MVC 구현을 살펴보겠습니다. 8부. spring-boot로 작은 애플리케이션 작성하기
코멘트
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION