5

I'm working on a new framework for PHP that utilises an architectural pattern called RMR, instead of the more common (pseudo)-MVC that most PHP frameworks currently implement. So far it feels like a better fit for web-apps than MVC was.

I'm currently separating the various concerns involved with managing a page request/response cycle and have so far implemented objects for form validation, representing the request, representing the response, a front controller to wrap a complete HTTP request/response, a resolver to route a request to the appropriate resource and so on.

This has led to an interesting question regarding separation of concerns, however.

In an MVC framework I'd normally have a form validation object and a business object (model) wrapped in a controller action. The action would validate the input and hand it off to the business object if it passed validation, or back to the view for error display.

However, in RMR, there is no controller. The architecture I'm considering has a form validation class like the MVC frameworks such as zend, but without a controller there isn't an obvious place to invoke it.

I could invoke the form validation object from within the resource (the RMR equivalent of a model), but this feels wrong, because the resource needs to know more about how it's going to be used in this case. I know from the description of RMR that this isn't completely avoidable, the resource has to be able to understand a HTTP request, but I'd rather keep it to a minimum if at all possible so that resources can still be used outside of the context of the RMR framework without major modification.

I could do form validation in the object that encapsulates the HTTP request, but this implies that the request object needs to know how the resource is intending to use the given input. For example, a resource representing a blog entry may allow comments to be added, votes to be collected or the original poster to edit it. If all three kinds of operations are submitted via a POST then the request object will need to be able to determine whether the given POST is for editing the blog, adding a comment or submitting a vote. If more functionality is added to the blog article resource, or if some functionality is removed, then the request needs to know about it. This seems to break encapsulation.

I also considered moving form validation to the front controller, but this would have similar problems to having it in the request object. The front controller would need to know something about the inner workings of the resource before it could validate input for it.

If anyone has any alternative approaches or commentary regarding this problem I'd appreciate any input you have. Maybe this problem is just highlighting that the approach I used in the past with MVC was wrong, and having form validation in the controller wasn't the proper way of doing things?

Improve this question
6
  • How would you handle "paging"? This certainly breaks MVC in principal as the Model needs to know the state of the Presentation.
    – James Anderson
    Commented Apr 30, 2012 at 7:51
  • Are you talking about pagination? That would work the same way as it does in MVC. The input includes a 'page' variable that's sent to the model/representation. The model/representation returns an array that an external view/template/presentation/whatever formats into markup/JSON/XML/etc. Model/representation doesn't need to know anything about the presentation (that's the Response's problem)
    – GordonM
    Commented Apr 30, 2012 at 8:09
  • In order for pagination to work the model needs to know how many "lines" the view supports, and, often the view needs to be aware of some model internals (is the list volatile etc.?) for this to work.
    – James Anderson
    Commented Apr 30, 2012 at 9:06
  • @JamesAnderson No it doesn't, the view just needs to iterate over the array of results the model returns, that's the same regardless of whether you're using RMR or MVC or anything else. Besides, this has pretty much nothing to do with the question I asked.
    – GordonM
    Commented Apr 30, 2012 at 9:08
  • its why its in a comment. Just curious about how this approach deals with a perennial problem in MVC.
    – James Anderson
    Commented Apr 30, 2012 at 9:10

1 Answer 1

Reset to default
1

In MVC, I firmly believe validation belongs in the Model. The Model is the authority on what the data is and what it is allowed to be. A Model should not allow a caller to set one of its fields to an invalid value, so it has to validate its inputs, and DRY means you do not duplicate that elsewhere.

So I guess that means in RMR, validation would go in the Resource. The Method would be responsible for handling a validation failure by returning a Representation of the form with an error message instead of the Representation of the successful result.

Improve this answer
1
  • I tend to do validation in 2 places. The models all have sanity checks on their setters that throw exceptions if you try to feed in invalid input, and I validate the input form before it gets presented to the model in the first place so I can handle errors in a more friendly way than by tossing an exeption at the user. I guess you just need to think in a different ray in RMR.
    – GordonM
    Commented May 12, 2012 at 9:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.