예를 들어 Todo List를 작성하는 경우 프런트엔드 MVC를 따르고 다음과 같이 작성합니다.
모델: 데이터베이스의 내용(텍스트, 완료 상태)에 해당하는 JSON 배열
보기: 인터페이스인 HTML 템플릿 또는 DOM 템플릿
컨트롤러: 사용자가 인터페이스에서 작업한 후 모델을 변경합니다
일반적으로 다음과 같은 관계가 있습니다(매우 정확하지 않으며 다양한 MVC 구현이 완전히 일관되지 않음).
모델 변경에 따라 전체 프로그램이 업데이트됩니다
뷰는 모델에 따라 렌더링되고 모델이 업데이트됨에 따라 업데이트됩니다
컨트롤러는 뷰에서 이벤트 트리거를 수신하고 모델을 수정합니다
전체적으로는 하나의 사이클입니다~ Model에서 시작하여 중간에 사용자 작업을 추가하고 다시 Model로 돌아옵니다
이는 인터페이스에서 데이터를 분리하고 프로그램을 단순화하기 위한 그래픽 작성 아이디어입니다.
즉, 인터페이스를 나타내는 최소한의 데이터를 모델로 추상화하고 최소한의 작업을 컨트롤러로 추상화합니다.
뷰는 모델에 따라 변경되며 사용자 요구에 따라 마음대로 변경할 수도 있습니다.
먼저 네이티브 PHP에 대해 이야기해 보겠습니다.
데이터 처리, 페이지는 서로 중첩되어 함께 표시됩니다.
MVC는 다릅니다. 데이터 처리와 표시가 분리되어 있습니다.
업무가 복잡하지 않을 때에는 기본적으로 V, C로 처리하시면 됩니다.
C형제는 데이터를 처리해 포장해 V에게 건넸다. V에게 엄숙하게 전하세요. "V형님, 데이터가 다 여기 있으니 가져가서 보여주세요!"
V는 "알았어 C형님!"이라고 말한 뒤 프런트엔드에 데이터를 표시했습니다. Brother V에는 Brother C가 제공한 데이터를 표시하는 데 사용되는 foreach와 유사한 구문도 있습니다.
때때로 사업이 복잡해지고 C 형제가 혼자 데이터를 처리하는 데 조금 지쳤기 때문에 C 형제는 M 형제에게 도움을 요청합니다.
M 형제는 C 형제가 반복적인 일을 하도록 돕고 그것을 처리한 후 C 형제에게 맡깁니다. 그러면 C 형제는 그것을 V 형제에게 넘겨줄 것이다.
기본 PHP는 아웃소싱과 같아서 종종 한 사람이 프런트엔드와 백엔드 작업을 처리해야 합니다.
MVC는 프런트엔드와 백엔드를 갖춘 성숙한 회사와 같습니다. 업무 분업이 명확합니다.
모두가 개념에 대해 이야기했습니다. 사실 MVC의 의미는 미묘하게 바뀌었습니다. CS 소프트웨어의 원래 MVC와 오늘날의 PHP Ruby Python의 MVC에는 큰 차이가 있습니다. 오래전부터 MVP가 된 개념일 수도 있는데 다들 MVC에 익숙해서 오해하고 계시네요
실제 프로젝트 측면에서 세 가지 사고 실험을 해보면 MVC의 본질과 목표를 대략적으로 이해할 수 있을 것 같아요. 유연성과 유지 관리 가능성은 단지 성적인 수단일 뿐입니다
데이터베이스 선택 변경
데이터 구조는 변경되지 않습니다. 데이터베이스를 mysql에서 pgsql 또는 mongodb로 마이그레이션할 때 프로젝트에 얼마나 많은 변경이 필요합니까?
이상적인 MVC 아키텍처는 비즈니스 코드(모델 포함)를 수정할 필요가 없고 구성 파일만 수정하면 되며 기껏해야 새 DBAL 드라이버를 작성하면 됩니다
실제 상황에서는 서로 다른 DB의 성능에 미묘한 차이가 있으며, 이는 모델을 미세 조정하여 해결해야 합니다.
답이 공백인 경우 다시 작성하는 것과 거의 같습니다. 그러면 M 레이어가 충분히 독립적이지 않으며 모델에 작성된 코드를 다른 곳에 분산시켜야 할 때입니다
모바일 HTML5 버전
모든 기능이 변경되지 않고(모두 합리적이고 자연스러운 모바일 버전 상호 작용이 있음) 사이트에 모바일 버전을 추가한다고 가정하면 프로젝트에 얼마나 많은 변경이 필요합니까?
대답은 뷰 세트를 다시 작성한 다음 컨트롤러를 한 줄로 변경하는 것입니다if(isMobile) use(MobileView);
컨트롤러가 많은 로직을 변경해야 하고 심지어 모델까지 포함되어 있다면 V 레이어가 충분히 독립적이지 않은 것입니다
API 추가
모든 기능이 변경되지 않는다고 가정할 때, 사이트에 공개 API를 추가하는 경우(제3자 또는 모바일 애플리케이션에서 사용하기 위해) 프로젝트에 얼마나 많은 변경이 필요합니까?
대답은 새로운 인증, 데이터 형식 및 확인 논리와 간단한 보기(json 또는 xml만 출력)를 포함하는 새로운 컨트롤러 세트여야 합니다
모델을 변경해야 하거나 원본 뷰의 일부 항목을 이동해야 하거나 이전 컨트롤러에 원래 작성된 코드의 일부를 복사해야 하는 경우 C 레이어가 충분히 독립적이지 않은 것입니다
가장 생생하고 간단한 것은 MVC를 우리가 어렸을 때 즐겼던 카드 기반 게임 콘솔과 비교하는 것입니다.
남: 게임 카드이고, 데이터를 저장하고, 비즈니스 로직 등을 담당합니다.
뷔: 게임화면을 담당하는 TV입니다
C: 처음 두 핸들 사이의 상호 작용을 담당하는 게임 제어 핸들입니다
쇼핑사이트를 예로 들어보겠습니다.
M은 데이터 모델을 제공합니다. 예를 들어, 웹사이트의 사용자 데이터에는 사용자 이름, 비밀번호, 이메일 주소가 포함됩니다. 각 사용자는 여러 주문을 할 수 있으며 각 주문에는 주문 번호, 가격 등이 있습니다.
V는 제품 목록 표시 및 개인 내역 주문 표시와 같이 표시되는 HTML 인터페이스의 모습인 보기를 제공합니다.
C는 M에서 데이터를 추출한 다음 이를 V에 표시하는 컨트롤러입니다. 예를 들어, 귀하가 지난 주의 개인 주문 내역을 확인하고자 할 때, V는 M으로부터의 모든 주문을 찾고, 일주일 전의 주문 데이터를 필터링한 후, 나머지를 V에게 제공하여 표시하는 역할을 담당합니다.
MVC를 이해하기 위한 전제조건은 코드 레이어링의 개념이고, 코드 레이어링의 목적은 디커플링입니다.
두 가지 질문에 답해 보세요:
코드를 분리해야 하는 이유는 무엇인가요?
어떻게 분리하나요?
코드를 분리해야 하는 이유
소프트웨어는 사용자가 뷰에서 비즈니스 요구사항을 트리거하는 것부터 시작하여 특정 비즈니스 로직에 따라 요구사항을 처리하는 프로그램, 그리고 뷰에서 처리 결과가 사용자에게 피드백되는 것까지 전체 프로세스의 코드는 다음과 같습니다. 뷰 작업, 비즈니스 로직 처리, 뷰와 비즈니스 로직 간의 연결이라는 세 가지 주요 작업을 담당합니다.
프로그램에서 코드가 계층화되지 않은 경우 이 세 가지 측면의 구현이 하나의 클래스에 결합됩니다. 코드의 유지 관리성, 가독성 및 유연성(@mcfog의 답변 참조)을 위해 이러한 코드는 측면에 따라 서로 다른 클래스로 작성된 다음 동일한 측면을 가진 클래스를 패키지에 넣어야 합니다. 마치 서로 다른 수준에 있는 것처럼요.
분리하는 방법
mvc는 성숙한 계층형(분리형) 솔루션입니다.
첫 번째 질문에 대한 답변에 따르면, 다양한 수준의 코드를 다양한 클래스(및 패키지)에 넣어야 하는데, 이러한 다양한 수준의 코드가 어떻게 협력합니까?
이 질문에 대한 다른 답변은 이 질문에 대해 구체적으로 사진과 텍스트로 답변한 것 같습니다.
모델의 코드는 비즈니스 로직을 담당합니다.
보기의 코드는 사용자 상호 작용을 담당합니다.
컨트롤러의 코드는 모델과 뷰 간의 연결을 담당합니다.
C: 컨트롤러 - 비즈니스 로직을 처리하는 방법 이 "처리"는 주로 두 가지 목적에 해당합니다. 한쪽 끝은 모델에서 처리에 필요한 데이터 소스를 요청하는 것이고, 다른 쪽 끝은 처리 결과를 일부 뷰에 전달하는 것입니다. 방식; 중간에 있는 구체적인 프로세스는 컨트롤러가 담당하는 수준입니다
V: 보기 - 비즈니스 처리 결과를 고객에게 제시하고 상호 작용을 제공하는 방법
사실 너무 단순하게 말하는 것은 좋지 않습니다. 일부 세부 사항은 단순성을 위해 고도로 요약되고 추상화될 수 있기 때문입니다. 이를 뒷받침할 충분한 지식과 경험이 없으면 안개 속에서 꽃을 보는 것과 같습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
예를 들어 Todo List를 작성하는 경우 프런트엔드 MVC를 따르고 다음과 같이 작성합니다.
일반적으로 다음과 같은 관계가 있습니다(매우 정확하지 않으며 다양한 MVC 구현이 완전히 일관되지 않음).
전체적으로는 하나의 사이클입니다~ Model에서 시작하여 중간에 사용자 작업을 추가하고 다시 Model로 돌아옵니다
이는 인터페이스에서 데이터를 분리하고 프로그램을 단순화하기 위한 그래픽 작성 아이디어입니다.
즉, 인터페이스를 나타내는 최소한의 데이터를 모델로 추상화하고 최소한의 작업을 컨트롤러로 추상화합니다.
뷰는 모델에 따라 변경되며 사용자 요구에 따라 마음대로 변경할 수도 있습니다.
대략:
또는:
다음 답변은 개인적인 의견이므로 틀렸다면 정정해 주시기 바랍니다.
먼저 네이티브 PHP에 대해 이야기해 보겠습니다.
데이터 처리, 페이지는 서로 중첩되어 함께 표시됩니다.
MVC는 다릅니다. 데이터 처리와 표시가 분리되어 있습니다.
업무가 복잡하지 않을 때에는 기본적으로 V, C로 처리하시면 됩니다.
C형제는 데이터를 처리해 포장해 V에게 건넸다. V에게 엄숙하게 전하세요. "V형님, 데이터가 다 여기 있으니 가져가서 보여주세요!"
V는 "알았어 C형님!"이라고 말한 뒤 프런트엔드에 데이터를 표시했습니다. Brother V에는 Brother C가 제공한 데이터를 표시하는 데 사용되는 foreach와 유사한 구문도 있습니다.
때때로 사업이 복잡해지고 C 형제가 혼자 데이터를 처리하는 데 조금 지쳤기 때문에 C 형제는 M 형제에게 도움을 요청합니다.
M 형제는 C 형제가 반복적인 일을 하도록 돕고 그것을 처리한 후 C 형제에게 맡깁니다. 그러면 C 형제는 그것을 V 형제에게 넘겨줄 것이다.
기본 PHP는 아웃소싱과 같아서 종종 한 사람이 프런트엔드와 백엔드 작업을 처리해야 합니다.
MVC는 프런트엔드와 백엔드를 갖춘 성숙한 회사와 같습니다. 업무 분업이 명확합니다.
모두가 개념에 대해 이야기했습니다. 사실 MVC의 의미는 미묘하게 바뀌었습니다. CS 소프트웨어의 원래 MVC와 오늘날의 PHP Ruby Python의 MVC에는 큰 차이가 있습니다. 오래전부터 MVP가 된 개념일 수도 있는데 다들 MVC에 익숙해서 오해하고 계시네요
실제 프로젝트 측면에서 세 가지 사고 실험을 해보면 MVC의 본질과 목표를 대략적으로 이해할 수 있을 것 같아요. 유연성과 유지 관리 가능성은 단지 성적인 수단일 뿐입니다
데이터베이스 선택 변경
데이터 구조는 변경되지 않습니다. 데이터베이스를 mysql에서 pgsql 또는 mongodb로 마이그레이션할 때 프로젝트에 얼마나 많은 변경이 필요합니까?
이상적인 MVC 아키텍처는 비즈니스 코드(모델 포함)를 수정할 필요가 없고 구성 파일만 수정하면 되며 기껏해야 새 DBAL 드라이버를 작성하면 됩니다
실제 상황에서는 서로 다른 DB의 성능에 미묘한 차이가 있으며, 이는 모델을 미세 조정하여 해결해야 합니다.
답이 공백인 경우 다시 작성하는 것과 거의 같습니다. 그러면 M 레이어가 충분히 독립적이지 않으며 모델에 작성된 코드를 다른 곳에 분산시켜야 할 때입니다
모바일 HTML5 버전
모든 기능이 변경되지 않고(모두 합리적이고 자연스러운 모바일 버전 상호 작용이 있음) 사이트에 모바일 버전을 추가한다고 가정하면 프로젝트에 얼마나 많은 변경이 필요합니까?
대답은 뷰 세트를 다시 작성한 다음 컨트롤러를 한 줄로 변경하는 것입니다
if(isMobile) use(MobileView);컨트롤러가 많은 로직을 변경해야 하고 심지어 모델까지 포함되어 있다면 V 레이어가 충분히 독립적이지 않은 것입니다
API 추가
모든 기능이 변경되지 않는다고 가정할 때, 사이트에 공개 API를 추가하는 경우(제3자 또는 모바일 애플리케이션에서 사용하기 위해) 프로젝트에 얼마나 많은 변경이 필요합니까?
대답은 새로운 인증, 데이터 형식 및 확인 논리와 간단한 보기(json 또는 xml만 출력)를 포함하는 새로운 컨트롤러 세트여야 합니다
모델을 변경해야 하거나 원본 뷰의 일부 항목을 이동해야 하거나 이전 컨트롤러에 원래 작성된 코드의 일부를 복사해야 하는 경우 C 레이어가 충분히 독립적이지 않은 것입니다
가장 생생하고 간단한 것은 MVC를 우리가 어렸을 때 즐겼던 카드 기반 게임 콘솔과 비교하는 것입니다.
남: 게임 카드이고, 데이터를 저장하고, 비즈니스 로직 등을 담당합니다.
뷔: 게임화면을 담당하는 TV입니다
C: 처음 두 핸들 사이의 상호 작용을 담당하는 게임 제어 핸들입니다
쇼핑사이트를 예로 들어보겠습니다.
M은 데이터 모델을 제공합니다. 예를 들어, 웹사이트의 사용자 데이터에는 사용자 이름, 비밀번호, 이메일 주소가 포함됩니다. 각 사용자는 여러 주문을 할 수 있으며 각 주문에는 주문 번호, 가격 등이 있습니다.
V는 제품 목록 표시 및 개인 내역 주문 표시와 같이 표시되는 HTML 인터페이스의 모습인 보기를 제공합니다.
C는 M에서 데이터를 추출한 다음 이를 V에 표시하는 컨트롤러입니다. 예를 들어, 귀하가 지난 주의 개인 주문 내역을 확인하고자 할 때, V는 M으로부터의 모든 주문을 찾고, 일주일 전의 주문 데이터를 필터링한 후, 나머지를 V에게 제공하여 표시하는 역할을 담당합니다.
MVC를 이해하기 위한 전제조건은 코드 레이어링의 개념이고, 코드 레이어링의 목적은 디커플링입니다.
두 가지 질문에 답해 보세요:
코드를 분리해야 하는 이유
소프트웨어는 사용자가 뷰에서 비즈니스 요구사항을 트리거하는 것부터 시작하여 특정 비즈니스 로직에 따라 요구사항을 처리하는 프로그램, 그리고 뷰에서 처리 결과가 사용자에게 피드백되는 것까지 전체 프로세스의 코드는 다음과 같습니다. 뷰 작업, 비즈니스 로직 처리, 뷰와 비즈니스 로직 간의 연결이라는 세 가지 주요 작업을 담당합니다.
프로그램에서 코드가 계층화되지 않은 경우 이 세 가지 측면의 구현이 하나의 클래스에 결합됩니다. 코드의 유지 관리성, 가독성 및 유연성(@mcfog의 답변 참조)을 위해 이러한 코드는 측면에 따라 서로 다른 클래스로 작성된 다음 동일한 측면을 가진 클래스를 패키지에 넣어야 합니다. 마치 서로 다른 수준에 있는 것처럼요.
분리하는 방법
mvc는 성숙한 계층형(분리형) 솔루션입니다.
첫 번째 질문에 대한 답변에 따르면, 다양한 수준의 코드를 다양한 클래스(및 패키지)에 넣어야 하는데, 이러한 다양한 수준의 코드가 어떻게 협력합니까?
이 질문에 대한 다른 답변은 이 질문에 대해 구체적으로 사진과 텍스트로 답변한 것 같습니다.
모델의 코드는 비즈니스 로직을 담당합니다. 보기의 코드는 사용자 상호 작용을 담당합니다. 컨트롤러의 코드는 모델과 뷰 간의 연결을 담당합니다.
모델 뷰 컨트롤러 모델, 뷰, 컨트롤러
모델: 데이터 모델
보기: UI 관련 요소
컨트롤러: 모델과 뷰를 연결하는 데 사용됩니다
간단할수록 좋죠?
M: 모델 - 데이터를 어떻게 모델링하거나 데이터를 표현하는 데 어떤 구조가 사용됩니까?
C: 컨트롤러 - 비즈니스 로직을 처리하는 방법 이 "처리"는 주로 두 가지 목적에 해당합니다. 한쪽 끝은 모델에서 처리에 필요한 데이터 소스를 요청하는 것이고, 다른 쪽 끝은 처리 결과를 일부 뷰에 전달하는 것입니다. 방식; 중간에 있는 구체적인 프로세스는 컨트롤러가 담당하는 수준입니다
V: 보기 - 비즈니스 처리 결과를 고객에게 제시하고 상호 작용을 제공하는 방법
사실 너무 단순하게 말하는 것은 좋지 않습니다. 일부 세부 사항은 단순성을 위해 고도로 요약되고 추상화될 수 있기 때문입니다. 이를 뒷받침할 충분한 지식과 경험이 없으면 안개 속에서 꽃을 보는 것과 같습니다.
위의 모든 답변을 읽은 후 마침내 깨달았습니다. V는 사용자가 보는 것이고, C는 사용자가 제어하고, M은 사용자가 접근할 수 없는 것입니다. C와 V를 통해 M을 제어할 수 있나요?
SO의 MVC에 대한 토론: MVC란 정말 무엇인가요?
간단히 말하면 데이터베이스(모델)과 데이터 표시(뷰) 코드를 함께 사용하지 마세요. 추가해야 할 비즈니스 로직이 있다면 컨트롤러(컨트롤러)입니다.