Data Auditing in NHibernate und SqlServer

Question

Ich verwende NHibernate für ein Projekt und muss ich tun, data auditing.Ich fand in diesem Artikel auf codeproject, der diskutiert, die IInterceptor Schnittstelle.

Was ist Ihre bevorzugte Art von Audit-Daten?Verwenden Sie Datenbank-Trigger?Verwenden Sie etwas ähnliches wie das, was Lesen Sie bitte im Artikel?

Answer 1

Für NHibernate 2.0, sollten Sie auch einen Blick auf Ereignis-Listener.Dies sind die evolution, die IInterceptor Schnittstelle und wir nutzen Sie erfolgreich für die überwachung.

Answer 2

[BEARBEITEN]

Post NH2.0 Freigabe, bitte schauen Sie auf die Ereignis-Listener, wie unten vorgeschlagen.Meine Antwort ist veraltet.

---

Die IInterceptor ist die empfohlene Methode zum ändern von Daten in nhibernate in einer nicht-invasive Weise.Es ist auch nützlich für die Entschlüsselung / Verschlüsselung von Daten, ohne dass Ihre Anwendung code kennen zu müssen.

Trigger in der Datenbank verschieben der Verantwortung der Protokollierung (eine Anwendung betreffen) in das DBMS-Schicht, die effektiv bindet Ihre logging-Lösung für Ihre Datenbank-Plattform.Durch die Kapselung der auditing-mechanik in das Persistenz-layer, den Sie behalten Plattform-Unabhängigkeit und code-Portabilität.

Ich benutze Abfangjäger in der Produktion code auditing in wenigen großen Systemen.

Answer 3

Ich bevorzuge die CodeProject Ansatz, den Sie erwähnt.

Ein problem mit der Datenbank-Trigger ist, dass es lässt Sie keine andere Wahl, als für die Verwendung der Integrierten Sicherheit gepaart mit ActiveDirectory-als Zugriff auf Ihren SQL-Server.Der Grund dafür ist, dass Ihre Verbindung Erben sollte, die Identität der Benutzer, der ausgelöst wird die Verbindung;wenn die Anwendung verwendet ein mit dem Namen "sa" account oder andere Benutzerkonten, die "Benutzer" - Feld wird nur reflektieren "sa".

Dies kann überschrieben werden durch erstellen einer benannten SQL Server-Konto für jeden Benutzer der Anwendung, aber dies ist unpraktisch für nicht-intranet, public facing web-Anwendungen, zum Beispiel.

Answer 4

Ich mag die Interceptor-Ansatz erwähnt, und verwenden Sie diesen auf das Projekt, das ich arbeite aktuell an.

Jedoch ein offensichtlicher Nachteil, der es verdient Hervorhebung, dass dieser Ansatz wird nur von audit-Daten änderungen, die Sie über Ihre Anwendung.Direkte Daten-Modifikationen, wie z.B. ad-hoc-SQL-Skripts, die Sie möglicherweise ausführen müssen, von Zeit zu Zeit (immer!) nicht auditiert werden, es sei denn, Sie daran zu erinnern, führen Sie die audit-Tabelle Insertionen an der gleichen Zeit.

Answer 5

Ich verstehe, das ist eine alte Frage.Aber ich möchte die Antwort auf diese im Licht der neuen Event-System in NH 2.0.Ereignis-Listener sind besser für die überwachung-wie-Funktionen als Abfangjäger.Ayende, schrieb ein großartiges Beispiel dafür, auf seinem blog im letzten Monat.Hier ist die URL zu seinem blog-post -

ayende.com/Blog/archive/2009/04/29/nhibernate-ipreupdateeventlistener-amp-ipreinserteventlistener.aspx

Answer 6

Als einen ganz anderen Ansatz, Sie könnte verwenden Sie das decorator-Muster mit Ihren repositories.

Sagen, ich habe

public interface IRepository<EntityType> where EntityType:IAuditably
{ 
    public void Save(EntityType entity);
}

Dann hätten wir unsere NHibernateRepository:

public class NHibernateRepository<EntityType>:IRepository<EntityType>
{
   /*...*/
   public void Save ( EntityType entity )
   {
       session.SaveOrUpdate(entity);
   }
}

Dann könnten wir mit einem Audit-Repository:

public class AuditingRepository<EntityType>:IRepository<EntityType>
{
   /*...*/
   public void Save ( EntityType entity )
   {
       entity.LastUser = security.CurrentUser;
       entity.LastUpdate = DateTime.UtcNow;
       innerRepository.Save(entity)
   }
}

Dann, mit einem IoC-Framework (StructureMap, Schloss Windsor, NInject), die Sie bauen könnten es alle, ohne den rest Ihres Codes alle wissen, Sie hatte überwachung geht.

Natürlich, wie man audit der Elemente kaskadiert Sammlungen ist ein anderes Thema ganz...