Controllo dei dati in NHibernate e SqlServer

Sto usando NHibernate su un progetto e ho bisogno di fare il controllo dei dati. Ho trovato questo articolo su codeproject che discute l’interfaccia di IInterceptor.

Qual è il tuo modo preferito di controllare i dati? Usi i trigger di database? Usi qualcosa di simile a ciò che è discusso nell’articolo?

Per NHibernate 2.0, dovresti anche guardare gli ascoltatori di eventi . Queste sono l’evoluzione dell’interfaccia di IInterceptor e le usiamo con successo per l’auditing.

[MODIFICARE]

Pubblica la versione NH2.0, guarda gli ascoltatori di eventi come suggerito di seguito. La mia risposta è obsoleta.


L’IInterceptor è il modo consigliato per modificare qualsiasi dato in nhibernate in modo non invasivo. È anche utile per la decodifica / crittografia dei dati senza che il codice dell’applicazione debba essere conosciuto.

I trigger sul database stanno spostando la responsabilità della registrazione (una preoccupazione per le applicazioni) nel livello DBMS che lega efficacemente la soluzione di registrazione alla piattaforma del database. Incapsulando le meccaniche di controllo nel livello di persistenza si mantiene l’indipendenza dalla piattaforma e la trasportabilità del codice.

Uso Interceptors nel codice di produzione per fornire auditing in alcuni grandi sistemi.

Preferisco l’approccio CodeProject che hai menzionato.

Un problema con i trigger di database è che non ti resta altra scelta che usare Integrated Security accoppiato con ActiveDirectory come accesso a SQL Server. Il motivo è che la tua connessione dovrebbe ereditare l’id quadro dell’utente che ha triggersto la connessione; se l’applicazione utilizza un account denominato “sa” o altri account utente, il campo “utente” rifletterà solo “sa”.

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

Mi piace l’approccio di Interceptor menzionato e lo uso sul progetto al quale sto lavorando attualmente.

Tuttavia, un ovvio svantaggio che merita di essere evidenziato è che questo approccio controllerà solo le modifiche dei dati effettuate tramite l’applicazione. Eventuali modifiche dirette dei dati come gli script SQL ad-hoc che potresti dover eseguire di volta in volta (succede sempre!) Non verranno verificati, a meno che non ti ricordi di eseguire gli inserimenti della tabella di controllo nello stesso momento.

Capisco che questa è una vecchia domanda. Ma vorrei rispondere a questo alla luce del nuovo Event System in NH 2.0. Gli ascoltatori di eventi sono migliori per le funzioni di controllo degli interceptor. Ayende ha scritto un grande 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

Come approccio completamente diverso, puoi utilizzare il pattern decoratore con i tuoi repository.

Dì che ho

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

Quindi, avremmo il nostro NHibernateRepository:

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

Quindi potremmo avere un archivio di controllo:

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

Quindi, utilizzando un IoC Framework (StructureMap, Castle Windsor, NInject) è ansible creare tutto senza il resto del codice ogni volta che si è verificato il controllo.

Ovviamente, il modo in cui controlli gli elementi delle collezioni in cascata è un altro problema interamente …