No, non penso che un controller Object Oriented in uno scenario come questo debba necessariamente essere legato al meccanismo di routing. È possibile utilizzare i modelli di facciata o di comando per chiamare un controller senza di esso (il controller) che conosca i dettagli di tale chiamata (o, più precisamente, senza che l'oggetto controller sappia più del necessario per la chiamata).
IMHO il vantaggio di passare per controllori procedurali a quelli orientati agli oggetti non sta necessariamente nel modo in cui può essere isolato dalla parte di rooting, ma più nel modo in cui puoi riutilizzare e organizzare più facilmente quei controller OO invece di procedurali. Qual è la stima approssimativa della percentuale di comportamenti simili tra tutti i controller procedurali? Potresti inserire tutto ciò in un controller OO "base" e quindi riutilizzarlo tramite ereditarietà o composizione (preferibilmente quest'ultimo) per passare quel comportamento comune a tutti gli altri controller, senza doverli duplicare ogni volta nel codice (o importazione incrociata degli script procedurali uno dentro all'altro).
==== aggiornamento
Come da commento qui sotto, ecco un esempio ispirato al vecchio modulo MVC di Spring Framework (v2):
- uno o più oggetti router . Gli oggetti router sono configurati con pattern URL e gli oggetti controller corrispondenti per ciascun pattern. In questo modo, quando il router viene colpito da una richiesta (che corrisponde a un determinato pattern URL), verrà creato un oggetto con i parametri di quella richiesta (qui è possibile specificare quanti più dettagli sulla richiesta effettiva) e chiamare l'oggetto controllore corrispondente che gli passa l'oggetto richiesta
In questo modo il tuo controller non solo è isolato dai dettagli di basso livello della richiesta, ma anche dal rooter (comunicano tramite un oggetto requet intermedio, né importa come è stato prodotto o consumato, rispettivamente)
-
più oggetti controller che si associano a uno o più pattern URL ciascuno. Generalmente creerai un'interfaccia per il controller e questa è l'unica cosa che il router conoscerà su ciascun controller. Quindi si implementa tale interfaccia nei controller effettivi in base alle esigenze aziendali. Qui trarrai il massimo vantaggio da OO, poiché puoi incapsulare un comportamento comune in una classe di controller Abstract che puoi quindi estendere per determinati controller, ecc.
-
finalmente avrai uno o più oggetti visualizza resolver . Questi controller verranno utilizzati dai controller per sapere quale vista mostrare quando eseguono l'elaborazione e creano un oggetto model . I resolver della vista associano semplicemente pattern (pattern) URL o controller (o) alle viste.
-
come detto prima il controller produrrà un oggetto modello . Questo ragazzo conterrà tutti i dati necessari in modo che la vista possa aggiornarsi per la determinata azione / flusso di lavoro
Considerazioni finali
-
in base a quale definizione di MVC abbracci, questa può essere o non essere un'implementazione kosher del paradigma. In alcune definizioni MVC si dice che la vista ha una sorta di hook o callback nel modello in modo tale che quando il modello cambia automaticamente la vista si aggiorna automaticamente, in altre parole, tutto ciò che il controller deve fare è cambiare il modello e non preoccuparsi la vista. In altre definizioni la vista deve essere notificata dal controllore che il modello è cambiato per aggiornarsi. Puoi andare in entrambi i modi, di solito per implementare la prima versione, avrai bisogno di una libreria JavaScript per aiutarti. Se vuoi stare alla larga da JS puoi semplicemente implementare la seconda versione e aggiornare la vista (tramite controller) quando il modello cambia.
-
assicurati di mantenere il modello, la vista e gli oggetti del controller separati in modo pulito (il più possibile). Il controller dovrebbe solo ottenere i dati di richiesta necessari e costruire il modello di conseguenza. Se passare dai dati della richiesta al modello è complicato, creare oggetti di servizio separati che si occupino di esso e fare in modo che restituiscano il modello al controllore in modo che possa passarlo alla vista (e notificarlo se necessario). Il controller si occupa solo di ottenere dati di input e passare il modello alla vista. La modella dovrebbe essere super stupida, senza logica aziendale o qualcosa del genere. Dovrebbe solo contenere i dati per la vista. La vista stessa dovrebbe riguardare solo la presentazione, cioè con la formattazione dei dati per l'utente, non con la logica aziendale o altri trattamenti pesanti dei dati del modello (il modello deve contenere i dati finali da visualizzare).