2010-05-26 2 views
5

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

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

ответ

8

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

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

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

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


Re ваши комментарии:

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

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

+0

Но с регистратором, извлеченным из реестра, модель имеет новую «скрытую» зависимость. Если я использую модель в другом приложении - возможно, без регистрации или хранения под другим ключом, тогда попытки получить логгер потерпят неудачу. Итак, должны ли все мои подклассы базовой модели содержать такие методы, как log(), setLogger(), getLogger()? Или это просто избыток? –

+0

Очень полезно, большое спасибо. ;-) –

6

Соглашаясь с Bill Karwin's comment, я бы также использовал один выход журнала, но также воспользовался возможностью для filter errors based on priority (например, есть также журнал firebug, который можно настроить с легкостью).

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

Смежные вопросы