К какому уровню относятся функции, такие как: кэширование и ведение журнала?

Question

Допустим, мой бизнес-уровень в настоящее время содержит набор DTO и отдельных классов обслуживания для взаимодействия с хранилищем данных.

Пример:

class PersonService
{
   IPersonRepository _personRepository;
   ILogging _logger;
   ICacheStorage _cache;
   // Constructor here to create concrete objects.

   public Person GetPersonById(int Id)
   {
       // error logging and caching here???
   }
}

Имеет ли смысл вести журнал и кэшироватьна этом слое?Или было бы более целесообразно, чтобы уровень службы приложений справлялся с этими проблемами?А может, вообще что-то еще?

Answer 1

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

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

Answer 2

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

Answer 3

Я бы сказал, что кэширование - это деталь реализации поиска данных.Что касается PersonService, у него есть PersonRepository, который он может использовать для получения своих данных.Факт, что это может быть в памяти или в БД, является деталью, о которой не нужно заботиться.Поэтому я говорю, что кэширование происходит на уровне доступа к данным.

Что касается ведения журналов, это может быть где угодно и где угодно.Там действительно нет "неправильного" места для регистрации.(Вот почему это обычно рассматривается как «сквозная проблема», и почему люди будут использовать AOP для регистрации, см. Обсуждение здесь: Рекомендации по AOP с C # )