Where does form processing belong in an MVC application?

Question

I found this question on stack overflow and I have a question about one of the answers:

In Zend Framework, forms are typically objects with decorators, but usually (I thought) processing is done using a combination of controllers and models, with the main objective to keep the controller as lightweight as possible, and each object responsible for its own state.

One of the answers said to use the form object itself as the place to encapsulate the form processing members. Is that a good practice?

For some reason that seems awkward to me. But it also seems awkward to do most of the work in either the database abstraction layer (Zend_Db_Table/Row) or the controller. Where is the best place to encapsulate form processing? Should you create separate classes for the form itself and another class for processing the form (which then deals with the DBAL)?

Edit: here is another SO post that asks a similar question, but the OP doesn't get a complete answer.

We want to know: where does each part of the form processing logic belong?

Answer 1

1. Validation logic belongs in the database, the domain model, and possibly the view model.

   I think most frameworks have Model decorators/attributes to define validation and View helpers to render the View from the Model, including client-side validation shininess. So try to let the framework do all that work for you and focus on the Model.

2. Business logic belongs both in the Model (domain-dependent logic) and the Controller (service-dependent logic).

   I tend to weight as much logic as I can in domain Model to keep the Controller light, as you say. But I generally prefer not to inject service dependencies in my domain layer, so some of that logic has to happen in the Controller.

Answer 2

Depends on the type of validation - when the validation logic is part of the business domain, e.g. format of a social security number, then the validation should be located in the model. If the validation logic only applies to a specific form, then put the validation into the form.

You do this because you want to be able to reuse the validation logic in possibly multiple forms.

Answer 3

The ever pertinent 'where the heck does validation logic go?!' question ;).

The answer is: It depends.

I like to apply the following ruleset:

First: database level validations that prevent me from putting in bad data

Second: view level validations that are a bit shinier to provide specific responses to the specific form

Third: javascript level validations that do dynamic validation to save them the hassle of clicking

submit->ohfrickmissedthat->fix->submit->ohfrickmissedthattoo

Obviously how far you follow this ruleset depends on how usable your application ought to be.

Answer 4

if you create an object that is mapped from your form and which maps to a database table, zend makes your life very easier at that point.

You should process your forms either at controllers or if it makes sense in a business delegate class. but be vary that you dont make too may layers. than you will have to pass around objects etc. it will be a mess and hard to maintain. i usually start at the controller, if there is not much business logic to perform.