Separação de preocupações em um framework RMR

5

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?

    
por GordonM 30.04.2012 / 09:32
fonte

1 resposta

1

No MVC, acredito firmemente que a validação pertence ao modelo. O Modelo é a autoridade sobre o que os dados são e o que eles podem ser. Um Modelo não deve permitir que um chamador defina um de seus campos para um valor inválido, portanto, ele precisa validar suas entradas e DRY significa que você não duplica isso em outro lugar.

Então, eu acho que isso significa que no RMR, a validação iria no recurso. O método seria responsável por manipular uma falha de validação, retornando uma representação do formulário com uma mensagem de erro em vez da representação do resultado bem-sucedido.

    
por 11.05.2012 / 17:58
fonte