Qual è il modello HMVC?

Question

la documentazione di Reading Kohana, ho scoperto che la differenza principale nella versione 3.0 è che si segue il modello HMVC invece di MVC come versione 2.x fa. La pagina su questo nei documenti di Kohana e quello su wikipedia in realtà non mi danno una chiara idea.

Quindi, domanda: qual è il modello HMVC e in che cosa differisce da MVC

?

Answer 1

Sam de Freyssinet (uno degli sviluppatori di Kohana) ha scritto un piuttosto articolo approfondito su HMVC , quello che è, e come può essere utilizzato.

Link è morto: New Link - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web- applicazioni-with-HMVC /

Answer 2

Sono attualmente in fase di sviluppo il mio PHP 5.3 HMVC framework chiamato Lega . Dato che io sono pesantemente investito in e venduto su HMVC, ho pensato che avrei potuto offrire un diverso punto di vista, e forse una migliore spiegazione del perché dovrebbe essere usato HMVC ed i benefici che porta.

Il più grande vantaggio pratico di utilizzare un'architettura HMVC è il "widgetization" delle strutture di contenuti. Un esempio potrebbe essere commenti, giudizi, Twitter o di alimentazione display blog RSS, o la visualizzazione di contenuti carrello per un sito di e-commerce. Si tratta essenzialmente di un pezzo di contenuto che deve essere visualizzato in più pagine, e forse anche in luoghi diversi, a seconda del contesto della richiesta HTTP principale.

framework MVC tradizionali generalmente non forniscono una risposta diretta per questi tipi di strutture di contenuto, così la gente in genere finiscono per duplicare e di commutazione layout, utilizzando aiutanti personalizzati, creare le proprie strutture di widget o file di libreria, o tirando nei dati non correlati da il principale controller richiesto di far passare alla visualizzazione e il rendering in un parziale. Nessuno di questi sono particolarmente buone opzioni, perché la responsabilità di rendere un particolare pezzo di contenuto o caricando i dati richiesti finisce che perde in più aree e ottenere duplicati nei luoghi viene utilizzato.

HMVC, o specificamente la possibilità di inviare sub-richieste di un controller per gestire queste responsabilità è la soluzione più ovvia. Se si pensa a quello che stai facendo, si adatta esattamente alla struttura di controllo. È necessario caricare alcuni dati sui commenti, e visualizzarli in formato HTML. Quindi si invia una richiesta al controller commenti con alcuni params, interagisce con il modello, prende una vista, e la vista visualizza il contenuto. L'unica differenza è che si desidera i commenti visualizzati in linea, sotto l'articolo del blog l'utente sta visualizzando al posto di una pagina completamente separato commenti completo (anche se con un approccio HMVC, si può effettivamente servire sia le richieste interne ed esterne con lo stesso controller e "uccidere due piccioni con una fava", come dice il proverbio). A questo proposito, HMVC è in realtà solo un sottoprodotto naturale di ricerca della modularità maggiore codice, riutilizzabilità, e mantenendo una migliore separazione delle preoccupazioni. Questo è il punto di HMVC di vendita.

Sam de articolo TechPortal di Freyssinet su scala con HMVC è interessante pensare, non è dove il 90% + delle persone che usano quadri HMVC sta per ottenere reali, pratici, i benefici giorno per giorno da esso.

Answer 3

HMVC è strettamente correlata con l'approccio "componente based" di dispacciamento. Fondamentalmente, invece di avere un unico dispatcher, che delega a un controller, ogni controllore può fungere esso auto dispatcher. Questo vi dà una gerarchia di controllori. Il design è più flessibile e provoca una migliore incapsulamento di codice, ma ad un prezzo più elevato di astrazione. Konstrukt è progettato intorno a questo modello.

Si veda anche questa risposta: https://stackoverflow.com/questions/115629/ semplice-php-routing-framework / 120411 # 120411

Answer 4

In Kohana, almeno, una richiesta HMVC è una richiesta HTTP che è servito "internamente": invece di essere rilasciato attraverso la rete, è indirizzato, inviato e gestito dal framework stesso. La somiglianza dei nomi "HMVC" e "MVC" è confuso dal fatto suggerisce una connessione sottostante tra i termini che in realtà non esiste: non è una variante minore o modifica dall'altra, sono cose completamente diverse. (HMVC è anche descritto come Ajax senza la richiesta lato client HTTP.) Enfasi su Kohana, e il supporto per "HMVC" significa che il quadro ha un forte sostegno per un servizio orientata un'architettura basata su HTTP.

Il vantaggio di questo schema architetturale è che, poiché la stessa "convenzione di chiamata" viene utilizzato per le richieste interne ed esterne, è banale per convertire le richieste di servizio "interni" alle richieste "esterni" o viceversa in caso di necessità.

Anche se questo è un modello di architettura sensibile, dandogli il proprio nome sembra inutile (Symfony2 descrive lo stesso concetto " sotto-richieste "), in realtà il nome sembra essere un termine improprio: non c'è alcuna particolare esigenza o bisogno che le richieste formano una gerarchia (diverso dal grafo delle chiamate standard di ogni imperativo programma); le richieste potrebbero facilmente essere ricorsiva, per esempio.

[ Aggiornamento Apr 2011, mar 2012:. Expanded sulla risposta in risposta alle osservazioni]

Answer 5

HMVC è gerarchica Model View Controller.In nel normale MVC ogni oggetto ha la sua interfaccia grafica MVC.But non v'è alcuna relazione tra l'oggetto e l'oggetto GUI genitore GUI Bambino a differenza HMVC. In HMVC ogni oggetto GUI ha accesso ai propri oggetti figlio e ognuno di oggetto figlio può accedere al suo oggetto padre.

Quindi, in ogni vista c'è un genitore view.Through cui può accedervi vista padre. Perché in ogni controller è presente un controller genitore attraverso il quale può passare l'evento al controllore genitore (Se l'evento non è nel suo campo di applicazione.)

Per i dettagli descrizione fai clic qui

Nuovo collegamento è questo indirizzo