Estou trabalhando em um novo framework para PHP que utiliza um padrão de arquitetura chamado RMR , em vez do mais comum (pseudo) -MVC que a maioria das estruturas PHP implementa atualmente. Até agora parece um ajuste melhor para aplicativos da web do que o MVC.
Atualmente estou separando as várias preocupações envolvidas no gerenciamento de um ciclo de solicitação / resposta de página e até agora implementei objetos para validação de formulário, representando a solicitação, representando a resposta, um front controller para envolver uma solicitação / resposta HTTP completa um resolvedor para rotear uma solicitação para o recurso apropriado e assim por diante.
Isso levou a uma questão interessante sobre separação de preocupações, no entanto.
Em uma estrutura MVC, normalmente tenho um objeto de validação de formulário e um objeto de negócios (modelo) agrupados em uma ação do controlador. A ação validaria a entrada e a entregaria ao objeto de negócios se ela passasse pela validação ou voltaria para a exibição para exibição de erro.
No entanto, no RMR, não há controlador. A arquitetura que estou considerando tem uma classe de validação de formulário, como as estruturas MVC, como zend, mas sem um controlador, não há um lugar óbvio para invocá-lo.
Eu poderia invocar o objeto de validação de formulário de dentro do recurso (o equivalente a RMR de um modelo), mas isso parece errado, porque o recurso precisa saber mais sobre como ele será usado neste caso. Eu sei da descrição do RMR que isso não é totalmente evitável, o recurso tem que ser capaz de entender um pedido HTTP, mas eu prefiro mantê-lo a um mínimo, se possível, para que os recursos ainda possam ser usados fora do o contexto do quadro RMR sem grandes modificações.
Eu poderia fazer validação de formulário no objeto que encapsula a solicitação de HTTP, mas isso implica que o objeto de solicitação precisa saber como o recurso está pretendendo usar a entrada fornecida. Por exemplo, um recurso representando uma entrada de blog pode permitir que comentários sejam adicionados, votos a serem coletados ou o pôster original para editá-lo. Se todos os três tipos de operações forem enviados por meio de um POST, o objeto de solicitação precisará determinar se o POST fornecido é para editar o blog, adicionar um comentário ou enviar uma votação. Se mais funcionalidade for adicionada ao recurso de artigo de blog ou se alguma funcionalidade for removida, a solicitação precisará ser informada. Isso parece quebrar o encapsulamento.
Eu também considerei mover a validação de formulário para o front controller, mas isso teria problemas semelhantes para tê-lo no objeto request. O front controller precisaria saber algo sobre o funcionamento interno do recurso antes de poder validar a entrada para ele.
Se alguém tiver quaisquer abordagens ou comentários alternativos sobre este problema, agradecemos qualquer contribuição que você tenha. Talvez esse problema esteja apenas destacando que a abordagem que usei no passado com o MVC estava errada, e ter validação de formulário no controlador não era a maneira correta de fazer as coisas?