MVC design question for forms

views:

answers:

+2 Q:

MVC design question for forms

Hi, I'm developing an app which has a large amount of related form data to be handled. I'm using a MVC structure and all of the related data is represented in my models, along with the handling of data validation from form submissions. I'm looking for some advice on a good way to approach laying out my controllers - basically I will have a huge form which will be broken down into manageable categories (similar to a credit card app) where the user progresses through each stage/category filling out the answers. All of these form categories are related to the main relation/object, but not to each other.

Does it make more sense to have each subform/category as a method in the main controller class (which will make that one controller fairly massive), or would it be better to break each category into a subclass of the main controller? It may be just for neatness that the second approach is better, but I'm struggling to see much of a difference between either creating a new method for each category (which communicates with the model and outputs errors/success) or creating a new controller to handle the same functionality.

Thanks in advance for any guidance!

+1 A:

My preference would be to keep it all in one controller. It keeps all the relevant processes for filling out the application/form in one place, although I'm not sure how "massive" you're talking about. If you do decide to split it out, I would not subclass off of the main controller, but just make a handful of independent controllers, perhaps related by name for ease of use down the road.

Ryan Elkins 2010-03-24 15:44:28

Thanks Ryan. Massive may have been an exaggeration, but there would probably be around 10 categories/methods, so I was starting to feel uncomfortable about whether this was bad design by storing all this in the one controller - but as you say, it does make sense as it is all part of the one form

kenny99 2010-03-24 15:48:23

Controllers are meant to handle the work for one "thing" - how granular you want to define that is up to you. There are pros and cons to both directions but I don't know if there is really a right or wrong way to go.

Ryan Elkins 2010-03-24 16:23:06

+1 A:

My preference would be to create triplet Form-Controller-Model for every form displayed to the user. Whenever user clicks on 'Next' button on a form its controller should talk to the back end manager which takes care of dispatching submit request to the next form in chain. Vice verse if 'Back' button is clicked. Last form has a 'Finish' button which will go to the manager and pass the last bits of information.

This will avoid inheritance, make your code more robust and testing of forms possible in isolation.

Boris Pavlović 2010-03-24 15:50:32

Cheers Boris, that approach makes sense too. I am using an ORM, where each model represents a database relation, however, within each category/subform i will likely be interacting with more than one model , so would your approach be workable in that case? Apologies if i've misunderstood

kenny99 2010-03-24 16:07:55

Cheers Kenny, there are models and models. MVC's model is an object which backs up the state of view, i.e. your form. Models that you are talking about are domain object models on the business logic side of the fence. It's like having a store. You will use different idioms to present products/services to customers and other for managing stocks and finance.

Boris Pavlović 2010-03-24 16:44:46

ansaurus

tags:

views:

answers:

MVC design question for forms

related questions