Можно ли сохранить код регистрации полностью вне бизнес-логики?

С помощью AOP я могу удалить код регистрации из моей бизнес-логики. Но я думаю, что он может быть использован только для регистрации простых вещей (например, вход / выход метода регистрации и значения параметров).

Однако что, если мне нужно что-то записать в моей бизнес-логике? например

public void SomeDomainMethod(string id)
{
   //Get user by Id
   User user = Users.Get(id);
   if (user == null)
   {
      Log.Warn("user is not existed");        //<----------------- Log A
      throw new InvalidOperationException("user is not existed");
   }

   //Step 1 
   while(true)
   {
       //do something
   }
   Log.Info("Step 1 is completed");            //<----------------- Log B

   //Step 2
   while(true)
   {
       //do something
   }
   Log.Info("Step 2 is completed");            //<----------------- Log C

}

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

Можно ли переместиться выше 3-х кодов регистрации из метода? Что лучше всего подходит для такой ситуации?

Конечно!

Но по моему опыту, есть два основных типа полезных журналов:

Все журналы: журналы построены с помощью профилирования API. Хорошо подходит для выявления проблем с производительностью и отчетности об исключениях. Очень шумный.

Журналы бизнес-событий : журналы, вызываемые в бизнес-логике. Все, что может беспокоить бизнес. Минимальный шум. Просто заметные, логичные, «деловые» события. Хорошо для аудита и KPI ...

Итак, я настоятельно рекомендую две вещи. Во-первых, делайте то, что делают другие инструменты мониторинга, такие как New Relic, и используйте API профилирования .NET ¹ . Во-вторых, регистрируйте логические бизнес-события в своей бизнес-логике . Ведение записи определенных событий является бизнес-логикой.

И, как правило, я бы не предложил AOP для любого вида ведения журнала ² . По моему опыту, вы либо хотите все , что означает, что вы используете профилировщик, или вы хотите, чтобы логические / бизнес-события. И в последнем случае, я думаю, проще всего вызвать регистратор в бизнес-логике.

^{1. А если серьезно, сэкономьте тысячи часов усилий и просто используйте существующий инструмент профилирования ...}

^{2. Конечно, это предполагает, что вы разделяете мое мнение о том, что аспект не является отличным местом для сокрытия бизнес-правил!}

Конечно, вы можете легко использовать АОП для этого. Просто рефакторинг частей

• Получить пользователя по Id
• шаг 1
• шаг 2

на отдельные методы (как вы должны были сделать, чтобы сделать ваш код чище). Теперь вы можете легко настроить инфраструктуру AOP для регистрации вызовов методов по вашему выбору ( как показано здесь ). Исключение может быть зарегистрировано непосредственно вызывающей стороной, нет необходимости использовать AOP для извлечения этого из бизнес-логики.

Для вашего редактирования:

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

Почему бы и нет? Если в «контексте бизнес-логики» вы хотите зарегистрировать «что-то», которое стоит зарегистрировать, и если этому «чему-то» может быть присвоено разумное имя, в большинстве случаев имеет смысл реорганизовать код в метод на свой. Если вы хотите использовать AOP, вам потребуется структурировать свой код так, как вам, вероятно, следовало бы структурировать его независимо от требований к ведению журнала. Вы можете интерпретировать это как недостаток AOP, или вы можете интерпретировать это как преимущество, так как это дает вам обратную связь, где ваша структура кода может быть улучшена.

Если журналирование не является частью бизнес-требований, то лучше, как вы говорите, полностью исключить его из своего кода.

Это означает, что вы действительно не хотите регистрировать такие вещи, как «шаг 1 завершен». Хотя вначале это может быть полезно для отладки, в процессе производства будет просто генерироваться гигабайт мусора, на который вы никогда не взгляните.

Если Step1Complete - это какое-то деловое событие, требующее дальнейших действий, то оно может быть показано через старое доброе событие, не заставляя вас вводить ILogger или подобное в ваш класс.

С помощью некоторого общего шаблона вы можете извлечь код регистрации из вашей бизнес-логики. Однако, возможно, вы не найдете в этом смысла

Например, при использовании слушателя (handcraft one или с использованием шины событий и т. Д.) Ваш код будет выглядеть следующим образом

public void SomeDomainMethod(string id)
{
   //Get user by Id
   User user = Users.Get(id);
   if (user == null)
   {
      listener.OnUserNotFound(userId);
      throw new InvalidOperationException("user is not existed");
   }

   //Step 1 
   while(true)
   {
       //do something
   }
   listener.OnStep1Finished(......);

   ...

}

Внедрив ведение журнала в слушателе, логика ведения журнала больше не входит в вашу бизнес-логику.

Однако вы можете обнаружить, что это не всегда реалистично, поскольку вы не всегда можете определить значимое событие вашей логики.

Другой подход заключается в использовании механизма, подобного Dtrace в Solaris, который позволяет вам внедрять в запущенные процессы (я полагаю, что есть способ сделать подобное в C #?), Чтобы журналы и сбор статистики можно было определять во время выполнения. Тем не менее есть и другие недостатки.

Другой подход состоит в том, чтобы отделить ведение бизнес-журналов и технических журналов. Затем мы можем назвать ведение бизнес-журнала «Аудит» и применить определенный набор бизнес-правил, таких как срок хранения и правила обработки, такие как Business Activity Monitoring.

С другой стороны, техническое ведение журнала, или просто «ведение журнала», является последним средством, чтобы оставить след технической проблемы. Он должен быть асинхронным, быстрым, терпимым к невозможности сохранения сообщения журнала. Кроме того, сообщения журнала должны проходить через наименьшее количество прокси-серверов, которое может быть близко к источнику проблемы.

Логика ведения журнала довольно разнообразна и тесно связана с реализацией, так что вам действительно нужно отделять ее от кода?

Логика аудита должна рассматриваться как логика домена и обрабатываться соответствующим образом.

Например, в шестиугольной архитектуре может быть порт аудита, а также порты клиента, хранилища и MQ (и, возможно, метрики и контроля). Это будет вторичный порт, т. Е. Активность на этом порту запускается бизнес-ядром, а не внешними системами.

Способы избежать регистрации непосредственно в классе или методе:

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

2. Выполните вызовы методов, которые уже используются для ведения журнала.

Действительно ли необходимо отделять логирование от бизнес-логики? Ведение журнала соответствует написанной бизнес-логике и, следовательно, имеет смысл находиться в одном классе / функции. Что еще более важно, это облегчает читабельность кода.

Однако, если вы действительно хотите отделить ведение журнала от своей бизнес-логики, вам следует рассмотреть возможность создания пользовательских исключений и передачи этих исключений для ведения журнала.

Нет не в с #

OP, ответ на ваш конкретный вопрос - нет, не в c #. Могут быть и другие, более естественные языки AOP, но все подходы к AOP в c #, которые я видел, могут применять только определенные формы поведения в контексте точки соединения , то есть должен быть поток управления между одним блоком кода и еще один. Аспекты поведения не будут выполняться в середине метода, за исключением, конечно, вызова другого метода.

Вы могли бы "apsect-ize" определенные биты регистрации

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

В любом случае, запись журнала не является аспектом

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

Другими словами, существует неразрывная логическая зависимость между записью журнала и тем, о чем пишется. Вы не можете обобщить это.

Но одитинг это

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