1

개요 : PHP를 사용하여 CMS를 구축 중이며이를 MVC를 사용하여 구현하려고합니다. this structure을 사용하여 코드를 확장하려고합니다. MVC의 정확한 표현을 나타내므로 매우 간단합니다. 내 데이터베이스와 통신하기 위해 나는 Domain Objects와 Data Mappers를 사용한다.PHP MVC 구현 모델, 뷰 및 컨트롤러 간 매핑

질문 : 1 : 모델, 뷰, 컨트롤러 사이의 1 매핑

  • 그것은 1가 정말 필요합니까?

예 : 블로그 항목 페이지를 표시 할 때 블로그 시스템의 경우, 내가 DisplayEntryController라는 컨트롤러 및 DisplayEntryView라는보기를 만들 것입니다. 뷰는 현재 블로그 항목을 검색하기 위해 DB와 통신하는 BlogMapper 클래스와 현재 블로그 항목에 대한 설명을 검색하기 위해 DB와 통신하는 CommentMapper 클래스에서 정보를 가져옵니다. 보기가 2 개의 모델 객체와 함께 작동한다는 것을 고려하면 좋은 실행입니까? 대안이 없다면? 그렇다면이 방법을 일반적인 방법으로 어떻게 구현할 수 있습니까?

  • 여러 컨트롤러가 한 페이지를 처리 ​​할 수 ​​있습니까? 위 예제의 경우, DisplayEntryController와 CommentController를 사용하여 블로그 항목을 표시하는 페이지의 관련 부분을 처리 할 수 ​​있습니까? 그렇다면 컨트롤러가 어떻게 조정됩니까?

감사합니다. 예제는 크게 감사하겠습니다.


웹에서 보았던 대부분의 PHP MVC 구현은 페이지 접근 방식을 사용하여 MVC를 구성합니다. 예 : 홈 페이지에는 하나의보기, 하나의 컨트롤러 및 하나의 모델이 있습니다. MVC에서 1 : 1 : 1 매핑을위한 라우팅은 MVC 구성 요소의 위치와 이름을 적용 할 수 있으므로 간단합니다. 홈 페이지에 대한 요청이있을 경우 HomeView HomeController 및 HomeModel과 같은 클래스를 자동으로 찾습니다.

큰 프로젝트에서는 분명히 잘 작동하지 않습니다. 복잡하지 않은 라우터를 만들거나 복잡한 의존성 주입 레이어를 추가하지 않고 여러 모델 (DataMappers), 다중보기로의 라우팅을 지원하려면 라우팅을 어떻게 처리해야합니까?

예 : 위에서 설명한 것처럼 블로그 항목을 표시 할 때 블로그 항목 코드와 설명 부분이 표시됩니다. 이를 위해 은 블로그 항목을 가져 오는 두 개의 DataMappers, 즉 과 블로그에 대한 설명을 반환하는 DataMappers와 통신합니다. DB에서 의 데이터를 가져 오기 위해이 두 데이터 매퍼와 함께 작동하도록보기 을 할당하려면 어떻게해야합니까?

+1

아니요, MVC 부분 사이에 1 : 1 : 1 매핑을 사용하는 것은 실제로 "잘못된 부분"이 동일한 "가중치 그룹"에 있지 않기 때문에 실제로 잘못된 것입니다. 컨트롤러와 뷰가 클래스 인 반면 모델은 레이어입니다. 그리고 여러 컨트롤러는 같은 페이지에서 접근 할 수 있지만, "좌표"가 무슨 뜻인지는 알 수 없습니다. –

+1

MVC에서 1 : 1 : 1 매핑을위한 라우팅은 MVC 구성 요소의 위치와 이름을 적용 할 수 있으며 홈 페이지에 대한 요청이있을 때 HomeView HomeController 및 HomeModel과 같은 클래스를 자동으로 찾습니다. 복잡한 종속성 삽입 레이어를 추가하지 않고 뷰가 여러 모델 (DataMappers)과 통신 할 때 라우팅을 어떻게 처리합니까? –

+1

예 : 위에서 설명한 것처럼 블로그 항목을 표시 할 때 블로그 항목 코드와 주석 섹션을 표시합니다. 이를 위해 블로그 항목을 가져 오는 DataMappers와 블로그에 대한 설명을 반환하는 DataMappers 두 개와 통신합니다. DB에서 데이터를 가져 오기 위해 뷰를이 두 데이터 맵퍼와 함께 사용하도록 할당하는 방법은 무엇입니까? –

답변

2

모델, 컨트롤러 및보기의 1 : 1 매핑이 필요하지 않습니다.

MVC는 애플리케이션을 처리하는 데있어 계층화 된 접근 방식의 개념으로 작동합니다. 각 계층은 '에이전트'에 의해 처리되어 적절한 방식으로 구현됩니다. 이를 더 설명하기 위해 다음 시나리오를 고려하십시오.

데이터를 처리 한 다음 저장할 사람에게 넘겨 줘야한다고 가정합니다. 정보를 필요할 때 다시 사용할 수있는 한 데이터를 저장하는 위치와 데이터를 저장하는 방법은 상관하지 않습니다.데이터 처리에 대해 행복하게 이야기하고 '예를 들어'이것은 클라이언트 X의 프로젝트 데이터입니다. 저장하십시오. '라고 말한 다음 나중에'클라이언트 X의 프로젝트 데이터를 제공 할 수 있습니까? '라고 말하십시오.

그래서 MVC는 데이터 저장소 직원이 모든 데이터를 함께 버리거나 버려두 든 상관없이이 접근 방식에서 작동합니다. 그러나 중요한 것은 전송 및 검색 할 때 두 당사자 간의 인터페이스입니다. 예를 들어 클라이언트 데이터 또는 프로젝트 데이터 또는 둘 다로 정보를 저장하도록 결정할 수 있습니다.

마찬가지로 에이전트가 데이터를 수집하여 처리 할 수 ​​있습니다. 그들이 사용하는 인터페이스의 수 (예 : 전화, 웹, 이메일, 모바일 장치)는 신경 쓰지 않지만 사용자가 어떤 데이터를 제공하는지 신경 써야합니다. 물론 웹 정보 만 처리해야한다는 규칙이있을 수 있습니다. 따라서 데이터 수집을위한 인터페이스가 다를 수 있습니다.

따라서 각 에이전트는 가장 효율적인 방법을 사용하고 (심지어 결합 또는 분할하여) 시스템을 측면에서 작동시킬 수 있으므로 데이터 매핑이 없습니다.

+1

합리적인 것 같습니다. 그러나 웹에서 본 대부분의 PHP MVC 구현은 페이지 접근 방식을 사용하여 MVC를 구성합니다. 예 : 홈 페이지에는 하나의보기, 하나의 컨트롤러 및 하나의 모델이 있습니다. 이것은 분명히 큰 프로젝트에서 잘 작동하지 않습니다. 복잡하지 않은 라우터를 만들지 않고 여러 모델, 다중보기로의 라우팅을 지원하기 위해 라우팅을 처리해야합니다 (1 : 1 : 1 매핑에서 페이지 이름을 사용하여 HomeModel HomeController 및 HomeView를 찾는 것처럼 쉽습니다)? –

+1

올바른 관찰. 비즈니스 객체 기반 접근 방식을 사용하는 것이 좋습니다. 이것은 대개 데이터 테이블 (예 : Order)로 표시됩니다. 그러나 그것은 컨트롤러의 기초가되어야합니다. 자신에게 "어떤 비즈니스 기능이 허용되는지 물어보십시오." 이것에 대한 답은 컨트롤러 동작 (추가, 삭제, 인쇄, 검색 등)을 형성하고 뷰 (예 : 주문 페이지) 및 모델 (예 : 주문, 주문 항목, 제품)을 나타냅니다. – crafter