Fat controllers vs many small controllers

[eluser]Michael;[/eluser]
In a case like this, it comes down to personal preference. I would probably prefer to keep all the reports in one controller, unless there is a more logical breakdown ( like Accounting, Administrative, etc ), then you might split it up a bit more.

That said, however, I would more than likely create one controller that has the logic for all 14 reports. Assuming a report method wouldn't be very big ( mine hardly ever are ) you'll still have a fairly small footprint with the controller.

[eluser]Mirage[/eluser]
For your reports, I'd group that functionality into a single controller. Perhaps I'd give each report it's own model - depends how much the processing varies. Your controller is your traffic-cop. I/O only.

Two approaches:

1. One method per report
This would probably be my choice, especially if the reports have a varying number of views. Load the appropriate model and dispatch the processing to it, apply the results to the appropriate view.

2. One method for all reports
Using the _remap function, you can evaluate the URI for the report name and view, dispatch and render. This provides you with a bit more dynamics and compact code if you have a good naming/mapping strategy.

You can combine the two approaches by checking [in the _remap method] whether an appropriate method exists in your controller and hand off processing to it. This is a good way to help you handle exceptions to the default report processing flow.

So with a good naming convention or mapping approach you can compress this all into a single controller with a single method. Using many models you can separate the code for each report into manageable portions. But if you found yourself writing a giant 'switch' inside _remap, you might as well use approach 1.

For sake of consistency, I tend stay with approach 1 because it works well for all kinds of requests and CI handles the 404 situation for me.

HTH
-m

[eluser]Sarfaraz Momin[/eluser]
I learnt and implemented CI for the first time in one the critical sites which was expected to get good amount of hits. I was fairly new to MVC as well so I did not knew what optimized MVC was all about so I ended up making 1 controller for frontend 1 from backend admin and 1 for wildcard subdomains which are categories of the site. I didn't knew that the code I wrote was good or bad but its comfortably acheiving 75K+ uniques a day with almost 200K+ views. Which I suppose is atleast good for an application. I am sure the client will end up rewriting it but I don't think he would require that anytime soon.
Well with the above info I want to let you know that I didn't knew what sort of structure should I follow for my apps in CI.
I now belive strongly in getting things as structured as possible with my controllers not getting very big at all. They are really more smaller which helps me manage them better.
Hope I made some sense here.

Good Day !!!


Good Day !!!

[eluser]Colin Williams[/eluser]
Just curious. By what benchmark are you defining a Controller as "fat?" 10 lines, 20 lines, 50 lines or more? I personally have no problem with a controller method getting "fat." If it's got a big responsibility, it might require a lot of code. Also, sometimes I myself start to fragment/abstract things way too much and it becomes more difficult to follow and maintain.

My suggestion would be don't worry about size, worry about scope and clarity.

[eluser]Mirage[/eluser]
[quote author="Colin Williams" date="1217909187"]Just curious. By what benchmark are you defining a Controller as "fat?" 10 lines, 20 lines, 50 lines or more? I personally have no problem with a controller method getting "fat."[/quote]

I don't use the line count as a general measure unless I think that code becomes too unreadable. What counts is what those lines do and whether they repeat a lot.

If it's got a big responsibility, it might require a lot of code.

I tend to think that controllers have a very clear pre-defined responsibility: To collect input from the request, validate and clean it, hand it off to proper application facilities for processing, collect all data and hand that to the view. Therefore controller functions usually look pretty equivalent to me and don't really do much of any processing themselves.

This may seem overkill for smaller applications or some ad hoc code. But I've kind of settled on this approach as my 'best practice'. If something goes awry or needs to be worked on I always know where to look.

Also, sometimes I myself start to fragment/abstract things way too much and it becomes more difficult to follow and maintain.

Oh yes, I've been there as well. These days I don't break out and fragment because of readability, but rather look at 'useful' re-usability of code, level of sharing [between controllers]. Therefore, nowadays my controllers are mostly 'lean', as are my views and my models are fat. Also, when I begin an application/site I don't worry too much about it, but generally re-factor as the project begins to take shape.

My suggestion would be don't worry about size, worry about scope and clarity.

My sentiments exactly.

Cheers
-m

[eluser]Michael;[/eluser]
I tend to not worry about the size in terms of lines, or even the number of methods. I'm currently working on an app that has a controller that tops out at about 600 lines and 33 methods and the construct ... but it *flies*.

It's more about streamlining your code; removing unnecessary steps, utilizing proper queries, and reusing code as much as possible. In this particular controller 24 methods are nothing more than rule and field defines for form validation and I reuse the form function over and over and over and over ... I swear I will have nightmares tonight and the form is gonna get me!

In the end I define a fat controller as one that I have to actually *look* for what I am trying to find because I can no longer keep track of where everything is.

[eluser]jleequeen[/eluser]
Honestly, I don't know what my definition of a fat controller is. When I made the post, I was thinking more along the lines of maybe 20-30 methods, not as much number of lines per say. I basically just wondered whether when controller size becomes unmanageable (whatever that means to the programmer) when is it time to start breaking the controller down into smaller units. Speed was not really of as much concern to me as maintainability is. After all, that is the purpose of moving from spaghetti code to something more structure like CI.

Thanks to CI Mirage and Michael for your very useful insights, they have really helped.

[eluser]alboyd[/eluser]
I realise this is an old thread - but I don't see how resurrecting this one would be so bad!

I'm a relative newby with CI - in particular with things like that discussed in this thread. This has been a bit of an eye opener to me - i'm self taught in every way - never had a formal instruction on how to programme.

Tonight I was just becoming overwhelmed with my code and frustrated that I let the code get away from me. I feel as if everything I have written for this application I am working on has turned into spaghetti.

1. I have 32 views so far.
2. I have a BaseController which holds some shared functions and my other controllers extend this. it's small at the moment.
3. I have 2 models and all they do is define a query, execute a query and return a result to my controller.
4. I have 2 other main controllers ( they work with their respective model ), one is 500 lines and the other is 1500 lines. The 1500 line one I often get lost and can't find what I am looking for.

I gather from what i have read in this thread - I have need to seriously look at my methodologies!

On top of all that - this particular app is basically 90% AJAX using JQuery from the views and so I have a minefield of JQuery code (currently all contained within each view but probably later to be moved into separate js files).

Arrgghh (thanks for listening)

[eluser]Colin Williams[/eluser]
There's no arbitrary range that is or isn't acceptable. All parts of your application, controller, view, model, library, helper, etc, should have this many lines: No more than necessary, no less than necessary. That said, you should always be seeking for simplification and refinement, but just get the thing working first, then trim it down. It's like the question about acceptable number of queries. What you want to avoid is repeating the same queries or similar queries too many times.

Also, alboyd, there's no way we can use that info and say whether or not your app is well structured.

[eluser]jedd[/eluser]
[quote author="alboyd" date="1250624923"]I realise this is an old thread - but I don't see how resurrecting this one would be so bad![/quote]

Resurrecting old threads is bad for a number of reasons - not least is that it bothers (much like this post will) a bunch of people who probably don't loiter around here anymore.

Old threads tend to be old because they are resolved - so they're a little quanta of knowledge tucked away. If you have the same question, and it wasn't answered in the thread, then start a new thread. If you have a slightly different question, then start a new thread.


As to your problem ...

One thing that new programmers often have a hard time getting their head around is the idea of throwing code away. Actually, old programmers do too. It's a tough call, but sometimes you need to re-design. Not so easy if you're on a tight schedule, and it's your day job, of course.

It sounds like you might benefit from a few simple changes:

Put your views into sub-directories (based on controller they're called from).

Use an IDE that lets you fold code down - so you're only looking through code you're actively working on

Use an IDE that lets you browse based on function name, rather than just showing the raw code alone - this makes it much faster to move around

Start using phpdoc (or similar) to regularly document your own project, and have that in a browser right next to your application browser - so you can quickly identify functions you need, identify duplicates that you can remove, or places that you can replace several functions with one that's a bit more generic

Consider moving your common functions to a library, or a series of libraries, and/or a series of helpers - rather than loading up a BaseController. I use a MY_Controller extension, but it's very lightweight (a couple of hundred lines - mostly instantiating a number of menu arrays - low code complexity).

Move away from the one-model-per-table approach - or at least contemplate what would happen if you did this. You may be able to implement some private (_xyz) model functions that could abstract out some common tasks with your models, thereby reducing their complexity. Also look at MY_Model extension - I've found that a handful of functions in there reduces the repetitive nature of a lot of my DB queries in all my other methods.

1500 lines for a controller isn't bad, per se. A recent pseudo poll around here (relatively easy message to find because the thread subject wasn't hijacked by a subsequent thread! suggested most people aim for 600-800 lines for a controller. But a lot depends on the complexity of the code, the basic design decisions inherent in that construct, the comment:code ratio, and so on.

If you want some pointers, you can post code. Something this size might be best posted up on a public site - eg. github - as it's easier to use than a bunch of posted messages in a forum.

You'll have to get some pointers from others wrt AJAX .. I'm a JS noob.