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

Question

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

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

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

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

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

Answer 1

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

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

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