Avoiding massive controller: where to put individual files

Thanks for your response, Ivan. Your contributions are always very helpful.

When a controller is loaded its constructor is executed and then the specific method that router calls is executed. The other methods are "dead code" for the particular request.

I like CodeIgniter's basic routing approach very much, but I guess I agree you might have a lot of dead code in a file. I don't expect this will be much of a performance issue if one has APC or some other byte code caching module installed on their server. I both agree and disagree that it causes a code organization problem. Yes your controller files might get large, but you are allowed to use a directory to create multiple controllers. It's limited flexibility, but at least there is some flexibility.

For dealing with this problem there is an extreme, experimental maybe approach demonstrated by this framework: https://github.com/bluzphp
Here is a sample controller: https://github.com/bluzphp/skeleton/blob...ssword.php - it is not even a class, it is a function that is loaded only for a particular request. There is no dead code.

I've looked at it a bit. Looks like it uses a pretty generic namespace 'Application' but somehow manages to use anonymous functions. The function definition has a "use ($view)" syntax that I don't really understand.

Thanks for showing me, but I don't think I will be learning that framework.

Approximate simulation of this could be done in CodeIgniter if you have a separate controller for each possible request with a constructor and index method only. But this is quite extreme. Other methods could be implemented too, it is desireable the controller file not to excede about... let us say 400 lines.

Yes that does sound extreme -- and unnecessary I think. It sort of defeats the point of grouping common functionality into a common controller. Surely the point of putting multiple public methods in a single controller is to group like functionality such that those similar public methods can easily share non-public methods because they are all dealing with similar requests?

But to split a massive controller file into smaller ones brings another problem - where to put the common code for initialization that usually is put within the constructor. Some people make libraries and then load them manually within all the controllers. This may be done, but it is not convenient. Another way that is better IMO is using base controllers - see this: http://avenir.ro/codeigniter-tutorials/n...ontroller/

Well said! This is precisely what I'm doing now. So far, the only stuff that seems appropriate in base controller classes is session-related. I expect I will probably encounter more stuff that seems appropriate for a base class. My bigger concern is that I have a lot of 'cross-cutting concerns' such as a registry, sending email, etc. and I'm wondering where I should put code that is going to be used by many different controllers. My database classes seem pretty obviously to belong to the model directory, but I'm wondering about other code. I have some pretty elaborate purchase-related behavior that communicates with payment gateways and has all kinds of database interaction and logic branching depending on the database state. If that all ends up controllers, my controllers are going to be huge.


If you want to implement some pure classes that are not CodeIgniter-specific, see this: http://forum.codeigniter.com/thread-420.html

So, to have skinny controllers, move code as much as you can within models, libraries, helpers, classes, etc and adopt the base controllers concept.
[/quote]