Вход в MVC (Zend Framework)

Question

Существует ли передовая практика, когда нужно разместить функции ведения журнала в приложении MVC, например приложении Zend Framework (Zend_Log)? Должен ли я поставить логирование в контроллере или в модели? Или в обоих?

Если в обоих случаях они должны иметь один и тот же регистратор или отдельный?

Answer 1

Следуйте принципу Information Expert в рекомендациях GRASP для объектно-ориентированного проектирования:

... возложите ответственность на занятия с наибольшим количеством информации, необходимой для ее выполнения.

Таким образом, вы будете писать в журнал из класса, который содержит данные, которые вам нужны для регистрации. Если событие, которое вы хотите записать, относится к работе модели, то запишите в журнал в модели. Если событие, которое требуется записать, относится к работе контроллера, то пишите в журнал в контроллере.

Создайте один вывод журнала для приложения. В противном случае вам придется искать много журналов, чтобы найти любую диагностическую информацию! Вы можете сохранить объект журнала в Zend_Registry, чтобы вы могли вызывать журнал из любого класса в вашем приложении.

---

Ваши комментарии:

Лучше просто изящно выйти из строя, если регистратор не найден в ожидаемом разделе реестра. Под изящным сбоем я подразумеваю либо выводить ошибку в stdout (на веб-страницу), либо в stderr (в журнал сервера httpd), либо выдавать исключение и позволить приложению его обработать.

Что касается зависимостей, это не проблема. Каждый раз, когда класс использует другой класс, у вас возникает аналогичная зависимость. См. Шаблон проектирования Registry .

Answer 2

Соглашаясь с комментарием Билла Карвина , я бы также использовал один вывод журнала, но также воспользовался возможностью фильтрации ошибок на основе приоритета (например, есть и firebug регистратор, который можно легко настроить).

В нашем главном приложении мы получили db-writer (который превращается в RSS-канал в простом бэкэнде страницы), который также используется в качестве основного журнала и электронных писем для критических ошибок. Очень удобно для сортировки данных и получения статистики из них.