[eluser]Mirage[/eluser]
[quote author="michaelaball" date="1213746040"]I guess what I'm asking is, what degree of processing should be included in a controller? Is there any particular standard or convention? Is it simply for processing user I/O and then the real number crunching goes to library functions?[/quote]
There really isn't a standard or convention for either CI or other MVC frameworks. All you have is guidelines. Some MVC frameworks are more strict about their approach to separation, but that doesn't mean they're right. CI is much more loosely coupled, giving you the freedom to put things where they make sense for you.
Ideally, a controller shouldn't do anything but interpret the incoming request, invoke the appropriate Model[s] to gather up the business data and pass that data on to the View. While it's not against the 'rules', I don't let Model's communicate directly. Rather, the controller should collect data from one model and pass it to another if necessary.
Many view the Model as an abstraction of the database layer. It certainly is that because in most cases your dynamic data is stored in databases. But [in my book] a model is not 'only' that. Datas could come from webservices for example. There maybe a lot of conditional logic involved in a Modeling process that requires functions which have nothing to do with a database. In my application all of that nitty gritty nasty stuff goes in the Model. Model code is IMO the least reusable part of a web-application.
Libraries are the right place for a collection of functions encapsulating specific, reusable tasks in an object oriented manner. E.g. an email sending class. Other than the content, the process is always the same. So it's reusable across multiple applications. On the application level, libraries can also be useful to abstract away functionality that needs to be accessed by multiple models or controllers. I tend to use libraries if I write classes that depend on configuration. Otherwise, I'd create a plugin.
Hope this helps...
