Kohana의 문서를 읽었을 때 3.0 버전의 주요 차이점은 버전 2.x와 마찬가지로 MVC 대신 HMVC 패턴을 따르는 것입니다. Kohana의 문서와 wikipedia의 페이지에 대한 페이지는 실제로 명확한 아이디어를 제공하지 않았습니다.
질문 : HMVC 패턴은 무엇이며 MVC와 어떻게 다릅니 까?
답변:
Sam de Freyssinet (Kohana 개발자 중 한 명) 은 HMVC 에 대해, HMVC의 정의 와 사용 방법 에 대해 다소 깊이있는 기사를 작성 했습니다.
링크가 종료되었습니다 : 새 링크-https://web.archive.org/web/20160214073806/http: //techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/
현재 Alloy 라는 자체 PHP 5.3 HMVC 프레임 워크를 개발하는 중 입니다. HMVC에 많은 투자를하고 판매했기 때문에 HMVC를 사용해야하는 이유와 그 이점에 대해 더 잘 설명 할 수있을 것입니다.
HMVC 아키텍처를 사용함으로써 얻을 수있는 가장 큰 실질적인 이점은 컨텐츠 구조의 "위젯 화"입니다. 예를 들어 의견, 등급, Twitter 또는 블로그 RSS 피드 표시 또는 전자 상거래 웹 사이트의 장바구니 내용 표시가 있습니다. 기본 HTTP 요청의 컨텍스트에 따라 본질적으로 여러 페이지에 걸쳐 표시 될 수있는 컨텐츠의 일부입니다.
기존의 MVC 프레임 워크는 일반적으로 이러한 유형의 컨텐츠 구조에 대한 직접적인 답변을 제공하지 않으므로 사용자는 일반적으로 사용자 정의 헬퍼를 사용하여 자체 위젯 구조 또는 라이브러리 파일을 작성하거나 요청 된 기본에서 관련없는 데이터를 가져 와서 레이아웃 복제 및 전환 컨트롤러를 뷰로 밀어 넣고 부분적으로 렌더링합니다. 특정 콘텐츠를 렌더링하거나 필요한 데이터를로드하는 책임이 여러 영역으로 유출되어 사용되는 장소에서 복제되기 때문에 이들 중 어느 것도 특히 좋은 옵션은 아닙니다.
이러한 책임을 처리하기 위해 HMVC 또는 특히 하위 요청을 컨트롤러에 디스패치하는 기능이 확실한 솔루션입니다. 당신이하고있는 일을 생각하면 컨트롤러 구조에 정확히 맞습니다. 주석에 대한 일부 데이터를로드하고 HTML 형식으로 표시해야합니다. 따라서 컨트롤러에 일부 매개 변수를 사용하여 의견을 요청하고 모델과 상호 작용하고보기를 선택하면보기에 내용이 표시됩니다. 유일한 차이점은 주석이 완전히 별개의 전체 의견 페이지 대신 사용자가보고있는 블로그 기사 아래에 인라인으로 표시되기를 원한다는 것입니다 (HMVC 방식을 사용하더라도 실제로 동일한 컨트롤러 및 "kill"을 사용하여 내부 및 외부 요청을 모두 처리 할 수 있음 돌 하나가있는 두 마리의 새 "). 이와 관련하여 HMVC는 실제로 코드 모듈화, 재사용 성 향상 및 더 나은 우려 분리 유지를 위해 노력하는 자연스러운 부산물입니다. 이것이 HMVC의 판매 포인트입니다.
따라서 HMVC 로 확장하는 것에 관한 Sam de Freyssinet의 TechPortal 기사 는 흥미로울만한 것이지만 HMVC 프레임 워크를 사용하는 사람들의 90 % 이상이 실제적이고 실용적이고 일상적인 혜택을 얻을 수있는 곳은 아닙니다.
HMVC는 디스패치에 대한 "컴포넌트 기반"접근 방식과 밀접한 관련이 있습니다. 기본적으로 컨트롤러에 위임하는 단일 디스패처 대신 각 컨트롤러가 자체 디스패처 역할을 할 수 있습니다. 이것은 컨트롤러의 계층 구조를 제공합니다. 디자인은 더 유연하고 코드 캡슐화가 향상되지만 더 높은 추상화 비용이 듭니다. Konstrukt 는이 패턴을 중심으로 설계되었습니다.
이 답변도 참조하십시오 : https : //.com/questions/115629/simplest-php-routing-framework/120411#120411
Kohana에서 최소한 HMVC 요청은 "내부"로 서비스되는 HTTP 요청입니다. 네트워크를 통해 발행되는 대신 프레임 워크 자체에 의해 라우팅, 발송 및 처리됩니다. "HMVC"와 "MVC"라는 이름의 유사성은 실제로 존재하지 않는 용어 사이의 근본적인 연결을 제안한다는 점에서 혼동됩니다. 하나는 사소한 변형이 아니며 다른 하나는 완전히 다른 것입니다. (HMVC는 클라이언트 측 HTTP 요청이없는 Ajax라고도합니다.) Kohana의 강조 및 "HMVC"지원은 프레임 워크가 HTTP 기반 서비스 지향 아키텍처를 강력하게 지원함을 의미합니다.
이 아키텍처 패턴의 장점은 내부 및 외부 요청에 동일한 "호출 규칙"이 사용되므로 "내부"서비스 요청을 "외부"요청으로 또는 그 반대로 변환하는 것이 쉽지 않다는 것입니다.
이것은 합리적인 아키텍처 패턴이지만, 고유 한 이름을 부여하는 것은 불필요 해 보입니다 (Symfony2는 동일한 개념 " 하위 요청 "을 설명 함). 실제로 그 이름은 잘못된 것으로 보입니다 : 특별한 요구 사항이 없거나 요청이 계층 (모든 명령 프로그램의 표준 호출 그래프 제외); 예를 들어 요청은 쉽게 재귀적일 수 있습니다.
[ 2011 년 4 월 업데이트, 2012 년 3 월 : 의견에 대한 답변으로 확장되었습니다.]
HMVC는 계층 적 모델 뷰 컨트롤러입니다. 일반 MVC에서 모든 GUI 객체는 MVC를 갖지만 HMVC와 달리 상위 GUI 객체와 하위 GUI 객체 사이에는 아무런 관계가 없습니다. HMVC에서 각 GUI 개체는 자식 개체에 액세스 할 수 있으며 각 자식 개체는 부모 개체에 액세스 할 수 있습니다.
따라서 모든 뷰에는 상위 뷰가 있으며이를 통해 상위 뷰에 액세스 할 수 있습니다. 모든 컨트롤러에는 이벤트를 상위 컨트롤러로 전달할 수있는 상위 컨트롤러가 있습니다 (이벤트가 해당 범위 내에 있지 않은 경우).
새로운 링크는 이 주소입니다