Controller / View Relationship - Printable Version
+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Using CodeIgniter (https://forum.codeigniter.com/forum-5.html)
+--- Forum: Best Practices (https://forum.codeigniter.com/forum-12.html)
+--- Thread: Controller / View Relationship (/thread-67940.html)
Controller / View Relationship - simon - 04-28-2017
1 to 1 or 1 to many, is the question in short.
I'm coming from an ASP.NET C# Web Forms environment where forms/pages that are related to a business function are kept in the same folder. Web Forms has good security based on folders and only allowing users belonging to the permitted roles to access the pages in that folder. Much of the code is held in classes so the code behind the forms themselves can be quite light. We end up a structure that like:
example.com/ (public interface and many, many pages)
example.com/accounts (Accounts Department 'home' page and menu, accessed by Accounts and Managers)
... plus 100 more.
example.com/manager (Managerial section 'home' page, only Managers allowed)
... plus another 50 more.
For my CodeIgniter project, I'd assumed that I would have one controller per functional area (accounts, manager, etc), each with their many views. Each function within the controller would load the model for it's view. As with our ASP.NET folders, only users in the permitted roles would be able to access the views controlled by this controller and that it would pretty much mirror the above from the user's point of view. I want to leave aside the advanced opportunities presented by routing at this stage. The users are happy with the structure above.
My concern is that my controllers may get too big. For example, the 'accounts' role needs to access around 100 different views. They need to be able to access and update information on customer, invoices, suppliers, inventory and many, many more. The other few roles have fewer forms, but the same concept.
However, if you go for a 1 to 1 relationship between controller and view, it seems a bit of an abstraction to me. You might as well just have the model code in classes and mix what happens in the controller in with the HTML in a plain old PHP page. Which is what happens now in the Webforms system.
Is it best practice to have one controller per role and allow it to manage dozens of views or should I go the Apple way and have one controller for every view. Something in between maybe?
Thanks for any opinions.
RE: Controller / View Relationship - donpwinston - 04-28-2017
I'd do it the same way. Use an Account, Manager, ... etc controller and a function for each view. But there's no "best way".
RE: Controller / View Relationship - InsiteFX - 04-28-2017
See the CodeIgniter News Tutorial in the Users Guide.
RE: Controller / View Relationship - simon - 04-28-2017
(04-28-2017, 05:58 AM)donpwinston Wrote: I'd do it the same way. Use an Account, Manager, ... etc controller and a function for each view. But there's no "best way".
Thanks donpwinston, I think doing it this way would suit me, so that's good to hear.
RE: Controller / View Relationship - simon - 04-28-2017
I followed the News tutorial a few months ago and built the application successfully. A couple of sections in the text are what got me thinking about my question initially. One describes the controller as being the glue, the center of the application, and that had me thinking that perhaps fewer controllers are better, perhaps just one even. The other section is where I'm not sure if confirmation bias comes in, as they have a new controller for the News view, but say this could have been in the original Pages controller and that also meant fewer is better to me.
Thanks for leading me back to the tutorial. I think I should go with a controller per functional group and risk them being bigger.
RE: Controller / View Relationship - PaulD - 04-29-2017
I would avoid though the big fat controller if I were you.
For instance suppose your page has the following options and content:
With the page content for manager home page something like
I would have the following controllers
And view structure
So now, when you need to change the categories page in the manager, you would just be dealing with the categories.php controller, the categories models and libraries, and the page views in the manager/categories folder.
I also (these days) try to keep my controllers as thin as possible so the manager_home.php would look something like:
Now all the work and logic is being done in your libraries. Your libraries call models to query the database to get the data, so your libraries can be slim too. You can unit test your libraries quite easily.
Not saying this is the only or best way but is what I would do and it does keep everything very easy to maintain whilst avoiding big fat controllers. So not 1 to 1, nor 1 to many, but 1 to 'some' related methods. So I would have edit_user and add_user in the users.php controller, but keep them very, very thin and do all the actual work in libraries and models.
RE: Controller / View Relationship - InsiteFX - 04-29-2017
I have to agree with @PaulD, keep your Controllers small and lean place all business logic into your Models.
RE: Controller / View Relationship - simon - 04-29-2017
Thanks for that PaulD. It's an option I'd been thinking about, but had got fixated on just the two opposite options. It was good of you to lay it out like that for me too. I can definitely see how it can be applied to the Manager section in my project.
And I agree with yourself and InsiteFX, the bulk of the processing code will be in models. Some of the batch data processing routines are pretty complex and definitely do not belong in the controller.
RE: Controller / View Relationship - lillian - 05-11-2017
Thanks PaulD! I got it