1 or 5 controllers?

[eluser]adamp1[/eluser]
OK let me explain. I have currently 1 controller which contains all the methods to add/edit/delete/view 4 database tables, with an extra method to let you select which table to 'work' on. Now these tables are all linked and related to each other.

So would anyone here have a single controller like I have, its about 500 lines long or so OR have 5 controllers each with about 100 lines in, separating out the different tables?

Its nothing big or hard I just want to know what others may do in a situation like this.

[eluser]Elliot Haughin[/eluser]
I'd take option number 2...
A controller should really have some relation to the entity it uses. So a blog controller should mainly work with a blog table etc.

And, it's easier to manage code if it's split up in a nice logical way.

[eluser]adamp1[/eluser]
What about a controller just to display a menu to send you to the other 4? Basically its a ACL management panel, so you can manage permissions/resources/groups/actions. So all are tied into the same general area.

[eluser]Elliot Haughin[/eluser]
Hmm... It's difficult to judge without seeing the code and what your controller actually does.
But I always try to drill down as much as possible, and use libraries to put in common features that are used across multiple controllers.

[eluser]dtrenz[/eluser]
Without knowing the context/data better... I would probably do 1 controller.

I'm surprised you have 500 lines for such simple operations... are you sure your not putting too much code in your controller and not enough in your models?

[eluser]adamp1[/eluser]
The only code in the controller is for validating form input, and calling the views. But consider doing this 10 times, then the rest is comments and stuff.

I'm currently re-writing them putting them into separate controllers.

[eluser]frenzal[/eluser]
If the 4 tables don't have that much to do with each other I'd split it up otherwise leave it together, 500 lines isn't that bad

[eluser]wiredesignz[/eluser]
[quote author="adamp1" date="1205199897"]OK let me explain. I have currently 1 controller which contains all the methods to add/edit/delete/view 4 database tables, with an extra method to let you select which table to 'work' on. Now these tables are all linked and related to each other.[/quote]

What code do you have in your Models?

[eluser]adamp1[/eluser]
All code to handle the nested set trees which store all the permission data. Also methods to get the data out in a easy to handle way (IE so it can be displayed in a table/treeview/select menu).

I suppose I could move a bit more to the models, but not that much.

[eluser]MadZad[/eluser]
My knee-jerk reaction is to reduce the amount of code in that controller (splitting into multiple controllers is one option). You mentioned a lot of validation - can that functionality be bundled up into a helper function?

My reasoning is that you should be able to look at your controller code and clearly see the paths through the code. That is what is really important in a controller. When there's a lot of validation code, you can get caught up in a lot of details and lose sight of the big picture.

This may sound like a style issue, but one thing to consider is how will this code look in 6 months when you, or someone else, returns to it. Rather than seeing all the validation code amongst the controller flow, you could simply have:

Code:

if (! ($val_result = validate_my_first_input())) {
    //take error action, based on values in $val_result
}

Plus, when you make functionality modular, you facilitate refactoring and unit tests - two things that promote long-term code health.