Как разработать хороший алгоритм аудита? - PullRequest
2 голосов
/ 03 февраля 2012

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

На данный момент я создал простой метод для класса Singleton:

public void Audit(string audit, AuditTypes type)
{
    AuditEntry = new AuditEntry(){ Audit = audit, TypeId = (int)type };

    // some logic to commit the audit entry to the database
}

public enum AuditTypes
{
  Insert = 1,
  Update = 2,
  Delete = 3
  Open = 4
}

Где-то в формах я называю этот метод:

MyForm.cs:

private void RemoveSomeObject(SomeObject myObject)
{
   /* Do some stuff that removes the object*/

   MySingleton.GetInstance().Audit(myObject.Title, AuditTypes.Delete)
}

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

Я думаю, что разумнее сделать это более оригинально, как вы думаете? EDIT:

Я регистрирую идентификатор пользователя и дату, но не нашел это уместным для уведомления.

Ответы [ 4 ]

2 голосов
/ 03 февраля 2012

При формировании действий типа CRUD часто полезно инкапсулировать слой доступа к данным, используя Шаблон проектирования репозитория .У вас может быть базовый класс для ваших классов репозитория, который будет выполнять аудит для вас.

1 голос
/ 03 февраля 2012

Это классический пример Аспектно-ориентированного программирования .По сути, у вас есть сквозное требование, которое распространится на многие части системы (т. Е. Ведение журнала или аудит).Проблема в том, что ваш подход кажется правильным, но его сложно поддерживать и он плохо масштабируется.Если у вас есть время и желание, вы можете прочитать об этом и попробовать, используя PostSharp , у них есть бесплатная стартовая версия.Вы также можете проверить это: AOP в .NET

1 голос
/ 03 февраля 2012

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

Поэтому, чтобы обойти ваш синглтон, я бы вставлял экземпляр вашего Auditor всякий раз, когда вы выполняете операцию, требующую аудита:

private void RemoveSomeObject(SomeObject myObject, Auditer myAuditer)
{
    // do stuff //

    myAuditer.Audit(...);
}

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

0 голосов
/ 03 февраля 2012

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

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

...