Какой хороший пример cross-cutting concern ? Пример медицинской карты на странице википедии кажется мне неполным.
В частности, из этого примера, почему ведение журнала может приводить к дублированию кода ( разброс )? (Помимо простых вызовов, таких как log("....")везде, что не кажется большим делом).
В чем разница между core concern и а cross-cutting concern?
Моя конечная цель - лучше понять АОП.
Ответы:
До понимания концерна Crosscutting , мы должны понять Concern .
Беспокойство это термин , который относится к части системы , разделенной на основе функциональности.
Опасения бывают двух типов:
На этом рисунке представлено типичное приложение, разбитое на модули. Основная задача каждого модуля - предоставлять услуги для своего конкретного домена. Однако каждый из этих модулей также требует аналогичных дополнительных функций, таких как ведение журнала безопасности и управление транзакциями. Примером перекрестных проблем является «ведение журнала», которое часто используется в распределенных приложениях для облегчения отладки путем отслеживания вызовов методов. Предположим, мы ведем журнал как в начале, так и в конце тела каждой функции. Это приведет к пересечению всех классов, у которых есть хотя бы одна функция.
Я думаю, что лучшим примером сквозной проблемы является транзакционное поведение. Например, было бы отталкивать размещение блоков try-catch с вызовами фиксации и отката во всех ваших методах обслуживания. Аннотирование методов маркером, который АОП может использовать для инкапсуляции их с желаемым транзакционным поведением, является большим выигрышем.
Еще один хороший кандидат в качестве примера сквозной проблемы - авторизация. Аннотирование метода службы с помощью маркера, который сообщает, кто может его вызвать, и предоставление некоторым советам АОП решать, разрешать ли вызов метода или нет, может быть предпочтительнее обработки этого в коде метода службы.
Внедрение ведения журнала с рекомендациями АОП может стать способом повышения гибкости, чтобы вы могли изменить то, что регистрируется, путем изменения точки соединения. На практике я не часто вижу, чтобы проекты делали это. Обычно использование библиотеки вроде log4j, которая позволяет фильтровать по уровню ведения журнала и категории, во время выполнения, если вам нужно, работает достаточно хорошо.
Основная проблема - это причина, по которой приложение существует, бизнес-логика, которую приложение автоматизирует. Если у вас есть приложение для логистики, которое обрабатывает грузоперевозки, выяснение того, сколько груза вы можете упаковать в грузовик или какой лучший маршрут, чтобы грузовик отправился с доставкой, может быть основной проблемой. Сквозными проблемами обычно являются детали реализации, которые необходимо отделить от бизнес-логики.
В дополнение к принятому ответу я хочу упомянуть еще один пример сквозной проблемы: удаленное взаимодействие. Скажем, я просто хочу вызвать другие компоненты в моей экосистеме локально, как если бы они были запущены в процессе. Может быть, в некоторых случаях они и есть. Но теперь я хочу запускать свои сервисы, распределенные в облаке или кластере. Почему мне как разработчику приложения нужно заботиться об этом аспекте? Аспект может позаботиться о том, чтобы узнать, кому и как звонить, сериализовать передаваемые данные, если необходимо, и сделать удаленный вызов. Если бы все выполнялось в процессе, аспект просто перенаправлял бы локальный вызов. На вызываемой стороне аспект десериализует данные, выполняет локальный вызов и возвращает результат.
Теперь позвольте мне рассказать вам небольшую историю о «тривиальных» вещах, таких как вывод журнала: всего несколько недель назад я реорганизовал сложную, но не слишком большую базу кода (около 250 000 строк кода) для клиента. В нескольких сотнях классов использовался один вид фреймворка, в других нескольких сотнях - другой. Потом было несколько тысяч строкSystem.out.println(*)где действительно должен был быть вывод журнала. В итоге я исправил тысячи строк кода, разбросанных по всей кодовой базе. К счастью, я мог использовать некоторые хитрые приемы в IntelliJ IDEA (структурный поиск и замена), чтобы ускорить все действие, но, черт возьми, вам не кажется, что это было тривиально! Конечно, ведение журнала отладки, строго зависящее от контекста, всегда будет происходить в теле метода, но многие важные типы ведения журнала, такие как вызовы методов трассировки (даже иерархически с красиво оформленными выходными данными), регистрация как обработанных, так и необработанных исключений, аудит пользователей (ведение журнала вызовов к ограниченные методы, основанные на ролях пользователей) и т. д. могут быть легко реализованы в аспектах, не загрязняя исходный код. Обычному разработчику приложений не нужно думать об этом или даже видеть вызовы регистратора, разбросанные по базе кода.
Я могу дать аналогичные объяснения и по другим сквозным проблемам. Сохранение кода чистым и свободным от разброса и запутывания IMO - это вопрос профессионализма, а не что-то необязательное. И последнее, но не менее важное: он делает код читаемым, поддерживаемым и обновляемым. Аминь.
Перекрестные опасения - это сценарии, которые должны всегда присутствовать независимо от типа приложения.
Например, ведение журнала, безопасность, профилирование производительности, локализация, доступность, транзакция и т. Д. Независимо от программного обеспечения, которое мы создаем, ведение журнала необходимо (в противном случае, как кто-то будет отлаживать или получать некоторую соответствующую информацию из данных продукта). Безопасность (аутентификация / авторизация и т. Д.) Необходима там, где только аутентичный пользователь может войти в приложение с правильным набором привилегий. Нам нужно знать, как работает ваше приложение, затем нам нужно выполнить профилирование. В случае, если приложение используется международными пользователями (с их собственным локализованным языком), нам необходимо поддерживать то же самое в приложении. Доступность - это случаи, когда люди с ограниченными возможностями могут использовать наше приложение.
Теперь, независимо от того, является ли наше приложение настольным, веб-приложением и т. Д., Если оно должно использоваться конечными пользователями из разных регионов в производственной среде, тогда необходимы перекрестные разрезы. До сих пор я ничего не сказал о том, что такое приложение, и т.д., но дал список проблем, которые следует решить, прежде чем выпускать его для конечных пользователей в производственной среде. и это все о перекрестных проблемах (которые должны обрабатываться всеми приложениями / методами / классами, т.е. на разных уровнях).