Мое программное обеспечение находится в слоях, с четко определенным API между слоями. Я стремлюсь реализовать ведение журнала для этих API с самого начала, чтобы для любой конкретной транзакции я мог видеть, как это приводит к вызову API на каждом из нижележащих уровней: если есть ошибка, это поможет сузить ее до конкретного слой. Ведение журнала также поможет воспроизвести проблему, показывая журнал всех предыдущих, нормальных действий, которые привели к проблеме.
Я также добавляю утверждения в каждый слой, где могу, и регистрирую ошибки подтверждений.
Файл журнала, следовательно, часто показывает последовательность обращений к общедоступным API с сообщением об ошибке, сгенерированным изнутри: этого достаточно для диагностики проблемы.
Кроме того, я добавляю протоколирование на уровне отладки по мере необходимости: для устранения конкретных проблем во время разработки и / или после выпуска.
Мое объяснение заботы о ведении журнала частично объясняется следующим:
Чтобы исправить любую ошибку в выпущенном программном обеспечении, я зависим от файла журнала; и то же самое также часто относится к программному обеспечению в процессе его разработки.
Вы сказали,
Я нахожу, что редко украшаю классы более низкого уровня, такие как реализация ICakeRepository, средствами логгера, поскольку это кажется бессмысленным.
Я сказал,
Мое программное обеспечение находится в слоях, с четко определенным API между слоями. Я склонен к ведению журналов для этих API с самого начала ...
Думаю, мне лучше объяснить, что я имею в виду под "слоями", которые могут совпадать или не совпадать с вашими классами "более низкого уровня".
Например, моя система может иметь следующие слои:
- UI
- Бизнес-уровень (правила работы с данными)
- Уровень доступа к данным (для ввода-вывода базы данных)
- База данных
В этом случае у меня будут следующие интерфейсы или API, которые могут заслуживать регистрации:
- Между пользователем и пользовательским интерфейсом (т. Е. События пользовательского интерфейса, мышь и клавиатура)
- Между пользовательским интерфейсом и бизнес-уровнем (см. «Диалоговое окно смирения»)
- Между бизнес-уровнем и DAL
- Между DAL и базой данных
В качестве альтернативы система может представлять собой цепочку компонентов, соединяющих две равноправные конечные точки (менее очевидно, с «верхним» и «нижним» слоями).
В любом случае я регистрирую API-интерфейс, являющийся общедоступным фасадом каждого компонента, который удобен для регистрации по нескольким причинам:
- Не слишком сложно (фасад обычно проще, чем базовая / внутренняя реализация)
- Хорошее покрытие (если я регистрирую весь фасад, и если единственный путь к компоненту - через его фасад, то я знаю, что я зарегистрировал все, что входит в компонент)
- Хорошо работает с Законом Конвея : при отладке системы с несколькими компонентами, каждый из которых разрабатывается другой группой, один из повторяющихся вопросов звучит так: «Какой компонент неисправен, и, следовательно, какая группа должна отладить? "