Вход в систему MVC (платформа зенда)
Существует ли лучшая практика когда дело доходит до того, куда поместить регистрирующуюся функциональность в приложение MVC, например, приложение Платформы Зенда (Zend_Log)? Я должен поместить вход в систему контроллера или в модели? Или в обоих?
Если в обоих, у них должны быть тот же регистратор или отдельный?
2 ответа
Следуйте принципу Information Expert в руководстве GRASP по объектно-ориентированному проектированию:
...поместите ответственность в классы с наибольшим количеством информации, необходимой для ее выполнения.
Таким образом, вы будете писать в журнал из класса, который содержит данные, которые вам нужно записать в журнал. Если событие, которое вы хотите зарегистрировать, относится к работе модели, то пишите в журнал в модели. Если событие, которое вы хотите занести в журнал, относится к работе контроллера, то пишите в журнал в контроллере.
Создавайте один выход журнала для приложения. В противном случае вам придется просмотреть множество файлов журнала, чтобы найти какую-либо диагностическую информацию! Вы можете хранить объект журнала в Zend_Registry, чтобы вы могли вызывать журнал из любого класса вашего приложения.
По поводу ваших комментариев:
Лучше просто изящно отказать, если логгер не найден под ожидаемым ключом реестра. Под изящным отказом я подразумеваю либо вывод ошибки на stdout (на веб-страницу) или stderr (в журнал сервера httpd), либо выброс исключения и предоставление приложению самому его обработать.
Что касается зависимостей, то это не проблема. Каждый раз, когда класс использует другой класс, у вас возникает подобная зависимость. См. шаблон проектирования Реестр.
Согласившись с комментарием Билла Карвина , я бы также использовал единый вывод журнала, но также воспользовался возможностью фильтровать ошибки на основе приоритета (например, есть еще firebug регистратор, который можно легко настроить).
В нашем основном приложении у нас есть db-writer (который превращается в RSS-канал в простой серверной части страницы), который также используется в качестве основного журнала и электронной почты для критических ошибок. Очень удобно для сортировки данных и получения из них статистики.