Elaborazione MVC multiplo vs Processo MVC singolo

Penso che quello a cui stai pensando sia un concetto chiamato HMVC, che sta per Hierarchical Model View Controller.

Ciò significa che quando esegui il rendering della visualizzazione, puoi inviare una richiesta a un controller completamente diverso e restituire che visualizzare e farlo eco. Si comporta esattamente come una richiesta Ajax, tranne che non passa attraverso http, passa attraverso il framework e non fa una richiesta aggiuntiva.

Questo non è comune nella maggior parte dei framework e le persone che non conoscono HMVC non sanno cosa mancano. Pulisce un sacco di brutti modelli che vedi nelle normali applicazioni MVC.

Ad esempio, hai un carrello della spesa in ogni pagina. Non sarebbe bello fare una chiamata al controller del carrello della spesa dal tuo codice e quindi permetterlo di gestire il rendering e tutto il resto? Puoi mostrare viste differenti per stati diversi. Cercare di farlo in una classe o in un metodo di supporto è solo un disastro.

Comunque, quello per cui sei venuto qui è un quadro che funziona così. La risposta è Kohana . Ecco i pertinenti documenti .

Ecco un esempio in uso:
Request::factory('shopping_cart/display_items')->execute()-body;

Probabilmente non troverai un sapore di MVC che coinvolga una vista che fa qualcosa.

Come sapete, in MVC i Views dovrebbero essere il più "stupidi" possibile per ottenere una buona separazione delle preoccupazioni.

La richiesta viene indirizzata a un'azione su un controller che esegue tutta la logica del modello e decide cosa visualizzare e invia a una vista.

Dato che puoi riutilizzare il codice cliente e le visualizzazioni, non capisco quale aspetto di MVC trovi incompatibile con il principio DRY?

Se si desidera che ogni pagina si prenda cura della propria logica, ASP.NET ha il view-behind e il modello Page, ma poiché è essenzialmente una traduzione web di WinForms, la sua natura guidata dallo stato non è propriamente Web (dal momento che HTTP è senza stato), quindi l'attuale popolarità e migrazione degli sviluppatori in ASP.NET MVC.

Come ha detto StuperUser, MVC si basa sul fatto che Vista è "stupido" o "sottile" e onestamente, sembra che potresti avere un fraintendimento dei fondamentali di MVC da qualche parte (non necessariamente, difficile da fare, nella mia esperienza, dal MVC può essere difficile da capire se non spiegato bene), se ti stai ritrovando a copiare codice nei controller.

Detto questo, potresti voler dare un'occhiata alla struttura M-V-VM (Model, View, View-Model) utilizzata dalle tecnologie WPF e Silverlight di .Net (o almeno utilizzata a partire da 3.5). È basato su MVC, ma ha alcune delle sue regole e potrebbe essere più vicino a quello che stai cercando.

In CakePHP puoi fare ciò che chiedi con requestAction . Generalmente non è consigliato a causa di problemi di prestazioni, ma funziona bene, specialmente con i contenuti memorizzati nella cache.

ASP.NET MVC ha un 'RenderAction' che puoi chiamare dal codice inline nella tua vista. Non mi piace personalmente; Preferisco costruire modelli composti attorno a un layout e lasciare che i modelli di "vista principale" ne derivino.

Potrei usare un piccolo costruttore o fabbrica per istanziare il modello (composto) per aiutarmi a creare un'istanza della composizione. Questo è principalmente per mantenere i miei controllori puliti dalla conoscenza di altre sottoview.

Usando questa strategia posso avere ciascuna vista parziale staccare il suo sottomodello dal modello composto o fare in modo che il layout lo faccia per una vista parziale.