Controllo dei dati in NHibernate e SqlServer

Question

Sto utilizzando NHibernate su un progetto e devo eseguire il controllo dei dati.ho trovato Questo articolo su codeproject che discute l'interfaccia IInterceptor.

Qual è il tuo modo preferito di controllare i dati?Utilizzi trigger di database?Utilizzi qualcosa di simile a quanto discusso nell'articolo?

Answer 1

Per NHibernate 2.0 dovresti anche guardare Ascoltatori di eventi.Queste sono l'evoluzione dell'interfaccia IInterceptor e le utilizziamo con successo per l'auditing.

Answer 2

[MODIFICARE]

Dopo il rilascio di NH2.0, guarda gli Event Listener come suggerito di seguito.La mia risposta è obsoleta.

---

IInterceptor è il modo consigliato per modificare qualsiasi dato in ibernazione in modo non invasivo.È utile anche per la decrittografia/crittografia dei dati senza che il codice dell'applicazione debba saperlo.

I trigger sul database stanno spostando la responsabilità della registrazione (un problema dell'applicazione) al livello DBMS che collega efficacemente la soluzione di registrazione alla piattaforma del database.Incapsulando i meccanismi di controllo nel livello di persistenza si mantiene l'indipendenza della piattaforma e la trasportabilità del codice.

Utilizzo gli Interceptor nel codice di produzione per fornire controllo in alcuni sistemi di grandi dimensioni.

Answer 3

Preferisco l'approccio CodeProject che hai menzionato.

Un problema con i trigger del database è che non ti lascia altra scelta se non quella di utilizzare la sicurezza integrata insieme ad ActiveDirectory come accesso al tuo SQL Server.Il motivo è che la tua connessione dovrebbe ereditare l'identità dell'utente che ha attivato la connessione;se l'applicazione utilizza un account denominato "sa" o altri account utente, il campo "utente" rifletterà solo "sa".

Questo può essere sovrascritto creando un account SQL Server denominato per ogni singolo utente dell'applicazione, ma ciò non sarà pratico, ad esempio, per le applicazioni Web pubbliche non Intranet.

Answer 4

Mi piace l'approccio Interceptor menzionato e lo utilizzo nel progetto su cui sto attualmente lavorando.

Tuttavia, uno svantaggio evidente che merita di essere sottolineato è che questo approccio controllerà solo le modifiche ai dati apportate tramite l'applicazione.Eventuali modifiche dirette ai dati come script SQL ad hoc che potresti dover eseguire di tanto in tanto (succede sempre!) non verranno controllate, a meno che non ti ricordi di eseguire contemporaneamente gli inserimenti della tabella di controllo.

Answer 5

Capisco che questa sia una vecchia domanda.Ma vorrei rispondere alla luce del nuovo Event System di NH 2.0.Gli ascoltatori di eventi sono migliori per funzioni simili al controllo rispetto agli intercettori.Ayende ha scritto un ottimo esempio sul suo blog il mese scorso.Ecco l'URL del suo post sul blog:

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

Answer 6

Come approccio completamente diverso, potresti utilizzare il modello decoratore con i tuoi repository.

Di' che l'ho fatto

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

Quindi, avremmo il nostro NHibernateRepository:

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

Quindi potremmo avere un repository di controllo:

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

Quindi, utilizzando un framework IoC (StructureMap, Castle Windsor, NInject) potresti creare tutto senza che il resto del tuo codice sapesse che era in corso l'auditing.

Naturalmente, il modo in cui controlli gli elementi delle raccolte a cascata è tutta un'altra questione...