Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

up vote 2 down vote accepted
  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.

share|improve this answer

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.

share|improve this answer
    
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 Oct 26 '11 at 12:14
    
FYI, my comment above assumes the controller is part of the presentation layer. –  user25791 Oct 26 '11 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

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

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

share|improve this answer

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.

share|improve this answer
    
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 Oct 26 '11 at 12:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.