Is there a best-practice when it comes to where to put the logging functionality in an MVC application, for example a Zend Framework application (Zend_Log)? Should I put the logging in the controller or in the model? Or in both?
If in both, should they have the same logger or a separate one?
Follow the Information Expert principle in the GRASP guidelines for object-oriented design:
...place a responsibility in classes with the most information required to fulfill it.
So you would write to the log from the class that contains the data you need to log. If the event you want to log pertains to the work of the model, then write to the log in the model. If the event want to log pertains to the work of the controller, then write to the log in the controller.
Do create one log output for an app. Otherwise you'll have to hunt through many log files to find any diagnostic information! You can store a log object in the Zend_Registry so you can call up the log from any class in your app.
Re your comments:
Better to just fail gracefully if the logger is not found under the expected registry key. By fail gracefully I mean either output an error to stdout (to the web page) or stderr (to the httpd server log), or throw an exception and let the app handle it.
As for dependencies, this is not a problem. Any time a class uses another class you have a similar kind of dependency. See the Registry design pattern.
Agreeing with Bill Karwin's comment, I would also use a single log output but also take advantage of the ability to filter errors based on priority (for example, there's also a firebug logger which could be setup with ease).
In our main app, we got a db-writer (which is turned into an RSS-feed at a simple page backend) which is also used as the main-log, and emails for critical errors. Very handy for sortable data and getting statistics out of it.