[eluser]Myles Wakeham[/eluser]
There definitely seems to be a lot of confusion with noobs regarding the philosophy of MVC. Its almost like there needs to be an exam first so that people understand the role of seperation of UI, transforms and data. But alas....
Controllers that have functions in them that are used repetitively, where the function isn't a simple call from a UI element (ie. HTML page) back to the application are typically poorly designed and definitely not 'MVC friendly'. What I do (and forgive me if the syntax has changed but I'm still using 1.4.1 CI), is to use PlugIns as a repository for all of my function libraries and make sure the controllers just load and have access to the necessary plugins in their creation. I normally force the web page to act as the 'contract party' with the controller, so if a web page requests something, the controller is its point of communication. Like a butler at a restaraunt. And like a restaraunt, I can't (as a customer) expect to go into the kitchen and interact with the cooks. My 'contract relationship' is with the butler.
The 'butler' is indicative of the controller. If the controller needs to send me to another table, then they place the burden back onto me to interface with a different controller (ie. move). Therefore the controller never needs to communicate with another controller. They just all share a common function repository, like all butlers share access to the kitchen to order and get meals as they are prepared.
In this analogy, do butlers ever communicate with other butlers? Sometimes, but it should be rare. The controller sends back the redirection to the web page in order to send them somewhere else to do something. As the controller should be primarily a UI interface, then it means that its contract relationship should only be to a UI.
Myles