CodeIgniter Forums
Controller methodology question - Printable Version

+- CodeIgniter Forums (
+-- Forum: Archived Discussions (
+--- Forum: Archived Development & Programming (
+--- Thread: Controller methodology question (/thread-54737.html)

Controller methodology question - El Forum - 09-22-2012

Hello everyone!

I’m new to CI but I feel I understand the MVC methodology well enough to be dangerous.  

My question relates to the trade-offs (if any), or best practices when establishing controllers.  For instance, is it “better” to have one controller per view (page) or to lump many views into a master/main controller for the site?

I’m curious if there’s a performance tradeoff or perhaps some long-term maintenance issues that I should consider.

Any advice you care to offer would be greatly appreciated.


Controller methodology question - El Forum - 09-24-2012

Welcome Trip!

Quote:For instance, is it “better” to have one controller per view (page) or to lump many views into a master/main controller
This link is useful for static pages (ie, contact us, privacy policy, sitemap, terms of use, etc).
One controller, handling many static pages.

But for non static pages, there is no real true "what is best", it comes down to a combination of personal preference, your design goals, trade-offs from one method compared to another, etc.

For example, you might have a group of use cases all about Cars for Sale.
At first glance it may seem logical to have a controller called "cars" and then all your methods in that one controller. But when you dig a bit deeper, perhaps this is not the best idea because the controller will end up huge with many methods such as:
- create_ad
- edit_ad
- activate_deactivate_ad
- delete_ad
- view_all
- view_details
- filter
- check_is_owner
- contact_owner
- report_abuse
- admin_blacklist
- etc etc.

At this point your controller is going to be HUGE with potentially 1000s of lines of code.
It would be better to have a folder in your controllers called "cars" and then break each of the above methods into it's own controller file. But the trade off of this is that any helpers, libraries, models, etc that you want have to be loaded into each and every controller (or you create a "super car contoller" which auto loads all your assets, sets variables, etc, and have all your "car" controllers extend this super car controller).

I'm building a site about Australian capital cities (well, it's much more than just that, this is just one section of the site). There are 8 capital cities, so I have 8 folders (called its respective city name) in my base controller folder and each page for each capital city has it's own controller within its respective folder. They are tiny, just sets a few bread crumb variables and some meta data variable, so I could have very easily loaded them all into one city controller, but I chose this method of doing it for some reasons such as I have a nice URL that suits my needs and SEO goals (I could have used routes to fix this, but that involves extra code (thus potentially extra bugs) and extra http redirects for the user, increasing page load speeds), I know in the future I will have MANY pages, and having them all in one controller would mean I could end up with a massive controller (which means more code for the server to load at compile time), so you could call this "future proofing".

It all comes down to personal preference, site architectural goals, future proofing, etc etc. It comes with experience, good luck, hope this helped somewhat!!!

Controller methodology question - El Forum - 09-24-2012

Thanks boltsabre!

Your post was very helpful. That's the method I began last night and I recognize the advantages you pointed out. Your comments make sense. I've constructed each controller with unique meta data for the individual page. It seemed like the cleanest way to accomplish to incorporate SEO best practices.

I'll try to keep the folder structure organized and clean as well.

Have a great week!