The need for other controllers apart from a front controller?

Hey,

I’ve been scratching my head lately as to why I would need any other controllers apart from an abstract controller and a front controller?

I was about to do an IndexController class but I stopped to think about what might go in there. But I can’t think of anything that I might in there, that isn’t already declared in the abstract controller.

What are some things that normally would go in a specific controller for a specific page (ie index page)?

In my abstract controller I have a render() method which pretty much handles all the views for me.

Good post PCSpectra - although I think describing a Controller in this method makes it hard to distinguish from a Facade, or even Service Layer. As with many design patterns, the distinctions are sometimes little more than contextual based on intent. It’s also worth bearing in mind that MVC as described in classic design pattern texts does not translate to the web without some modification - the following descriptions reflect that.

Take 2 principle Controller type patterns:

Page Controller - takes routing information, directly invokes views and models for itself.

Front Controller - same thing really - just a bigger brushstroke, another layer of control that recieves the request and then invokes the relevant controller. More flexible than Page Controller and results in less duplication - FC can marshall application wide components for use by PC’s.

I think your asking yourself the wrong question. In classical MVC there is only one controller component, but when you begin follwing a model-2 implementation the need for a front controller adds another.

I think it’s a mistake to stop here even. Remember a controller is really any code that controls or coordinates actions between two or more other components, whether they be models or views or possibly something else.

What a controller coordinates is really dependent on your abstraction requirements, etc. MVC is just the most common pattern, but it’s intent remains the same regardless. IMHO

Cheers,
Alex

generally speaking, controllers contain methods specific to that page request. The FC maps a request to a method name. Each of the “sub” controllers are merely a collection of methods to be executed once the FC processes a request that invokes them. Unless each page of your website is identical, or has no dynamic elements, then it’s likely that each controller will need to contain different logic (or calls to Model logic) for stuff like form validation, database interaction etc.

I’m just starting to learn CodeIgniter, which has separate Controller, Model and View. In the database I have 4 tables, so have the Controller and Model for the index page and one each for the 4 tables (a total of 5).

Each of the Controllers call their separate Views.

I have found that by separating the Controllers and Models, it is a lot easier to find everything.

Google MVC, there is a lot of good information out there.

MVCs are good, but only if you use them correctly