Есть ли конкретный шаблон, который я могу применить для сбора данных за несколько операций?

Question

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

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

Для загрузки данных мне необходимо;

• Связь с веб-сервисом для получения данных.
  • Данные для сбора ;
    • Сводная информация о запросе веб-службы (идентификатор записи, тип, время последнего обновления и т. Д.)
    • информация о любых исключениях, которые генерируются во время вызова веб-службы.
    • время в секундах, затраченноедля извлечения данных (или исключения) из веб-службы
• Проверка полученных данных с помощью локальных правил проверки
  • Данные для сбора ;
    • Ошибки валидации.
    • Если допустимо, то XML-представление полученных данных и локальное представление одного и того же объекта.
• Сохранить проверенные данные в локальной базе данных
  • Данные для сбора ;
    • Любые исключения во время вызовов базы данных
• Сохранение записи аудита / истории с подробным описанием всей информации, собранной выше.

Подобный тип данных сохраняется при загрузке информации в веб-сервис, где мы собираем исключения во время обмена данными через веб-сервис / БД, ошибки проверки, полученные от веб-сервиса через FaultException, время, необходимое для связи веб-сервиса и т. Д.

Для моего текущего решения я в настоящее время создал объект AuditHistory с заполнителями для хранения различной информации и передаю ее методам различных классов и заполняю ее во время каждого вызова метода.В конце я просто сохраняю этот объект истории аудита.

Это работает, но кажется уродливым и неуклюжим.

Любые идеи приветствуются.

Answer 1

Одним из довольно быстрых решений, которое вы могли бы реализовать, является определение интерфейса аудита для каждого из ваших компонентов. Например, в c # вы можете создать следующие 3 интерфейса:

public interface IWebServiceAuditInfo 
{
int RecordId { set; }
string Type { set; }
ICollection<Exception> WebServiceErrors { set; }
Timespan TimeToComplete { set; }
}

public interface IValidationAuditInfo 
{
string ValidXML{ set; }
ICollection<Exception> ValidationErrors { set; }
Timespan TimeToComplete { set; }
}

public interface IDatabaseAuditInfo
{
ICollection<Exception> DatabaseErrors { set; }
}

Пока ваш объект AuditHistory может реализовывать все 3 интерфейса. Однако в будущем, если вы захотите немедленно зарегистрировать информацию для каждого из них, вы можете просто предоставить реализацию каждого интерфейса, который затем будет сохранен (возможно, с GUID для перекрестных ссылок, как упомянуто Полом Сонье) в базу данных немедленно.

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

Answer 2

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

В качестве альтернативы, если хотитеЧтобы придерживаться парадигмы ОО, вы можете попытаться включить Наблюдатель , сделав все, что вам нужно для отслеживания, наблюдаемыми и собрав их для сбора данных аудита.

Answer 3

Я думаю, что ваш подход работает, но я бы использовал другой метод;Я бы связывал каждый запрос с GUID и передавал этот GUID.Затем вы можете использовать этот GUID при ведении журнала, и в конечном итоге вы можете выполнить что-то, что будет «сшивать» различные записи истории аудита вместе на основе GUID, чтобы дать представление о потоке в системе.Это больше работы на стороне сервера, чтобы «сшить» различные журналы / отчеты обратно вместе, но это отделяет каждый компонент от любых зависимостей друг от друга;есть только строка, которую каждый из них должен использовать при ведении журнала.

Другое преимущество состоит в том, что вы получаете только возможность заниматься построением контрольного журнала, основанного на GUID запроса, когда вам действительно нужны данные,Таким образом, если полный контрольный журнал необходим только, скажем, для 2% вызовов, остальные 98% расходуют ресурсы, проходящие вокруг объекта AuditHistory, в котором нет необходимости.Эти ресурсы могут быть относительно небольшими, но есть все связанные с этим проблемы взаимозависимостей при изменении объекта AuditHistory, требуемых повторных преобразований и т. Д.