views:

255

answers:

4

In a web-based application that uses the Model-View-Controller design pattern, the logic relating to processing form submissions seems to belong somewhere in between the Model layer and the Controller layer. This is especially true in the case of a complex form (i.e. where form processing goes well beyond simple CRUD operations).

What's the best way to conceptualize this? Are forms simply a kind of glue between models and controllers? Or does form logic belong squarely in the M or C camp?

EDIT: I understand the basic flow of information in an MVC application (see chills42's answer for a summary). My question is where the form processing logic belongs - in the controller, in the model, or somewhere else?

+3  A: 

I'd say this should probably be seen as 2 separate actions...

  1. submitting the form (V -> C)
  2. processing the submission (C -> M)

Speaking in generics, I tend to think as each action as a message between the sections. The full series of messages would be something like this...

  • Display Form (C -> V)
  • Submitted by the user (V -> C)
  • Process contents (C -> M)
  • Processing finished (M -> C)
  • Display Results (C -> V)
chills42
A: 

Agree with chills42, but would add to stuff as much down into the model as possible.
When a user submits (V->C) it is going to be submitted to some controller, and I argue it's best if the controller just acts as a dispatcher to decide what happens next, possibly based on some simple data point. Let the model have a method (usually not strictly ORM or active record based) process the raw data and save it into the db if appropriate then simply return a status or throw an error.

A: 

Form processing should take place in the model, because that's the layer of the application that is receiving and processing data from controllers by the way of views. The controller moves it around, but as for the actual code execution, it should be happening in your models.

dmanexe
A: 

Although at first the idea of using V -> C, C -> M, M -> C looks good, any change to the form requires messing up with the controller+model+view. That should be avoided to keep the application logic simple. Here is a very simple extension to the framework that makes it really easy to handle web forms processing, by delegating the form processing logic to a separate class and keeping the MVC architecture to handle the application logic.

For each form you need to process, create a class derived from a generic "webform" class, or the codeigniter model class. Add methods like validate(), process(), display() to this class.

In the controller, the code becomes like this.

class User_controller {

function login()
{
     $form = new LoginForm(); // this is the class you would create
     if ($form->validate())
     {
         $data = $this->user_model->getUserData( $form->userid );
         // form processing complete, use the main "user" model to fetch userdata for display,
         // or redirect user to another page, update your session, anything you like
     }
     else
         $form->display();
}

}

The display method in the form class loads its own view, and populates post back data as desired. By using the above, there are few advantages:

  • You don't need to change your main controller if the form display or processing needs changes.

  • You don't need to change your user model either

  • Controller remains clean and handle the main page logic

  • User Model remains cleans and only interacts with database

The framework can itself be updated so that webforms can be loaded using

$this->load->form("login"); ......

However, that is only a suggestion that is useful for the codeigniter team.

Samnan