Какое самое связующее место для использования регистратора?

Question

Я написал программу диспетчера задач с использованием Java и на данный момент выполнил единую реализацию пользовательского интерфейса. На данный момент программа имеет 3 слоя. Уровень представления, который взаимодействует с доменным уровнем через контроллер прецедента и, наконец, уровень технических служб, используемый для сохранения. На данный момент пользователь может выполнить несколько действий, таких как добавление задач, редактирование состояния задачи и т. Д. Цель моего регистратора в этой схеме - отслеживать все действия, предпринимаемые пользователями. Итак, есть несколько мест, где я мог бы вызвать регистратор, чтобы написать команду. Я не буду вести запись в слое презентации, так как это было бы ужасным решением для дизайна, и поэтому я остался с контроллером, командный интерфейс (реализованный для обработки исполнения всех команд с целью реализации функций отмены/повтора), или в классах нижнего уровня, на которые фактически манипулируют, например, класс задачи.

Я думаю, что контроллер является относительно приличным вариантом для этого, поскольку он действует как точка контакта между слоем пользовательского интерфейса и доменом, поэтому все заметные команды в конечном счете проходят через контроллер, что позволяет легко проверить, что все важные методы регистрируются. Причина, по которой это не делается в контроллере, заключается в том, что она уменьшит сцепление, увеличит сцепление и потенциально приведет к раздутому контроллеру.

Конкретные команды являются еще одним потенциальным местоположением, поскольку они также имеют всю информацию, необходимую для ведения журнала. Это снова приведет к тому, что команды станут менее сплоченными и увеличит сцепление. Кроме того, если я не использую командный интерфейс для принятия действия над объектом домена, я потерял свой журнал.

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

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

Answer 1

Подумайте о практичности в первую очередь. Заготовка леса часто является обслуживанием &. Каждый слой в вашем дизайне является кандидатом на регистрацию, но по нескольким причинам.

, не зная иерархии объектов и дизайн ...

Переход от домена к UI, каждый слой представляет собой абстракцию или совокупность поведения предыдущего слоя. Вы должны задавать себе такие вещи, как уровень детализации, который вы ищете? Было бы полезно увидеть запись команды? Было бы также полезно просмотреть ведение журнала для каждого связанного вызова уровня домена? Не всегда можно легко расшифровать вызовы домена и связать их с определенной командой.