Sto lavorando a un nuovo framework per PHP che utilizza un modello architettonico chiamato RMR , invece del più comune (pseudo) -MVC che la maggior parte dei framework PHP attualmente implementa. Finora sembra essere più adatto per le applicazioni web di MVC.
Attualmente sto separando le varie preoccupazioni relative alla gestione di un ciclo di richiesta / risposta di pagina e fino ad ora abbiamo implementato oggetti per la convalida del modulo, rappresentando la richiesta, che rappresenta la risposta, un front controller per racchiudere una richiesta / risposta HTTP completa, un resolver per indirizzare una richiesta alla risorsa appropriata e così via.
Ciò ha portato a un'interessante domanda riguardante la separazione delle preoccupazioni, comunque.
In un framework MVC avrei normalmente un oggetto di convalida del modulo e un oggetto business (modello) avvolto in un'azione del controllore. L'azione convaliderà l'input e lo inoltrerà all'oggetto business se ha superato la convalida o tornerà alla visualizzazione per la visualizzazione degli errori.
Tuttavia, in RMR, non c'è nessun controller. L'architettura che sto considerando ha una classe di validazione del modulo come i framework MVC come zend, ma senza un controller non c'è un luogo ovvio per invocarlo.
Potrei invocare l'oggetto di convalida del modulo dall'interno della risorsa (l'equivalente RMR di un modello), ma ciò sembra sbagliato, perché la risorsa deve sapere di più su come verrà utilizzata in questo caso. So dalla descrizione di RMR che questo non è completamente evitabile, la risorsa deve essere in grado di capire una richiesta HTTP, ma preferirei mantenerla al minimo, se possibile, in modo che le risorse possano ancora essere utilizzate al di fuori di il contesto del quadro RMR senza modifiche importanti.
Potrei fare validazione di forma nell'oggetto che incapsula la richiesta HTTP, ma ciò implica che l'oggetto di richiesta deve sapere in che modo la risorsa intende usare l'input dato. Ad esempio, una risorsa che rappresenta un post di blog può consentire l'aggiunta di commenti, voti da raccogliere o il poster originale per modificarlo. Se tutti e tre i tipi di operazioni vengono inviati tramite un POST, l'oggetto di richiesta dovrà essere in grado di determinare se il POST specificato è destinato alla modifica del blog, aggiungendo un commento o inviando un voto. Se vengono aggiunte ulteriori funzionalità alla risorsa dell'articolo del blog o se alcune funzionalità vengono rimosse, la richiesta deve essere informata. Questo sembra interrompere l'incapsulamento.
Ho anche considerato di spostare la convalida del modulo sul front controller, ma questo avrebbe problemi simili ad averlo nell'oggetto request. Il front controller avrebbe bisogno di sapere qualcosa sul funzionamento interno della risorsa prima che potesse validare input per esso.
Se qualcuno ha qualche approccio o commento alternativo riguardo a questo problema, apprezzerei qualsiasi input tu abbia. Forse questo problema sta solo evidenziando che l'approccio che ho usato in passato con MVC era sbagliato e che la convalida della forma nel controller non era il modo corretto di fare le cose?