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?

4 Answers 4

  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.


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.

  • So it sounds like the only issue is validation. I thought the issue was the fat controller--not wanting the controller to handle too much because the controller is a "thow-away" class (i.e., not reusable). Like instead of the controller instantiating 10 objects, it only brings one reusable object into the mix that does the same thing after some preliminary validation (i.e. if ($request->isPost() && $form->valid($postData)) { $processor = new Processor(); ... }). I thought part of the form is presentation, and part of it is model--is that wrong? Where should the lines be drawn?
    – user25791
    Commented Oct 26, 2011 at 12:14
  • FYI, my comment above assumes the controller is part of the presentation layer.
    – user25791
    Commented Oct 26, 2011 at 12:19

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


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


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.

  • See also my comments above to BenR. I thought the more heavy lifting you remove from the controller the easier it is to maintain, because you are separating concerns and programming to the interface, etc. Can you elaborate more on what you mean by "business delegate class." Thank you
    – user25791
    Commented Oct 26, 2011 at 12:23

Your Answer

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