Implementazione di Audit Trail: Spring AOP rispetto a Hibernate Interceptor rispetto a DB Trigger

Question

Ho trovato un paio di thread di discussione su questo argomento, ma nulla che portasse un confronto di tutti e tre i meccanismi in un unico thread.

Quindi questa è la mia domanda...

Devo controllare le modifiche al DB: inserimento\aggiornamenti\eliminazioni negli oggetti business.

Posso pensare a tre modi per farlo

1) Trigger DB

2) Intercettori ibernati

3) AOP primaverile

(Questa domanda è specifica per Spring\Hibernate DBMS- immagino che sia neutrale rispetto a Java\c# o hibernate hibernate- ma se la tua risposta dipende da C++ o Java o da un'implementazione specifica di hibernate- specifica)

Quali sono i pro e i contro della scelta di una di queste strategie?

Non sto chiedendo dettagli sull'implementazione. Questa è una discussione sulla progettazione.

Spero che potremo renderlo parte della community wiki

Answer 1

Posso parlare solo di Triggers e NHibernate, perché non ne so abbastanza di Spring AOP.

Dipende, come sempre, da cosa è più importante per te.

Trigger DB

• sono veloci
• vengono sempre chiamati, anche da SQL nativo, Script, app esterne.
• scrivere dati nel DB di cui NH non è a conoscenza.Mancherà nella sessione corrente.(Che potrebbe portare a risultati inaspettati)
• di solito non so nulla della tua sessione (ad esempio:nome di login).

Intercettori/eventi di Hibernate

• non sono specifici del DBMS.
• consentirti un facile accesso alle informazioni aziendali, come la sessione utente, il nome della macchina client, determinati calcoli o interpretazioni, localizzazione, ecc.
• consentono la configurazione dichiarativa, come gli attributi sull'entità, che definiscono se l'entità deve essere registrata e come.
• consentono di disattivare la registrazione, questo potrebbe essere importante per aggiornamenti, importazioni, azioni speciali che non vengono attivate dall'utente.
• consentirti una visione dell'entità del modello di business.Probabilmente sei più vicino al punto di vista degli utenti.

Answer 2

Capisco che non è al 100% legati alla domanda, ma lo fa aggiungere valore con nuove opzioni.

Ci sono due modi in cui è possibile controllare cosa sta succedendo.

Lettura log delle transazioni: Se database è in modalità di recupero completo, allora tutti i dettagli su INSERT, UPDATE, DELETE e istruzioni DDL vengono registrati nel log delle transazioni.

Il problema è che è molto complesso da leggere perché non è supportata in modo nativo e che avrete bisogno di una terza lettura log delle transazioni parti, ad esempio ApexSQL Log o SQL Log Rescue (quest'ultimo è libero, ma supporta solo SQL 2000).

Il vantaggio di questo metodo è che letteralmente non è necessario apportare modifiche se non per mettere il database in modalità di recupero completo.

tracce di SQL Server: Le tracce saranno catturare tutto nel file di traccia tra cui selezionare le dichiarazioni che anche possono essere necessari per alcuni scenari di conformità. Il lato negativo è che le tracce sono file di testo che devono essere analizzati e organizzati.

Answer 3

Non riesco a pensare a una buona ragione per non usare database trigger per controllare le modifiche al database. Inserimenti, aggiornamenti ed eliminazioni possono potenzialmente colpire il database da varie fonti - trigger prenderà tutte queste cose; Hibernate, ecc non sarà.

Answer 4

I tink se si considera il controllo, è necessario considerare che cosa è per. In primo luogo, è quello di havea registrazione di chi cambiato cosa e cosa è cambiato in modo da poter tornare indietro cattive modifiche, è possibile identificare i problemi con il sistema (si può vedere quale delle diverse applicazioni differnt casued il cambiamento che aiuta a identificare rapidamente quali uno è rotto) e così si può identificare chi ha effettuato la modifica. L'ultimo può essere davvero fondamentale quando si tratta di individuare le frodi. Se si fa tutto dall'interfaccia utente, non vedrete mai la truffa commettere utente che cambia i dati nel backend per scrivere lui stesso un assegno. Se si fa tutto dall'interfaccia, probabilmente è necessario disporre di permessi impostati a livello di tabel, aprendo così la porta per frode per cominciare. Se si fa tutto dall'interfaccia non si sa quale impiegato scontento cancellato l'intera tabella utente per il valore di fastidio pura. Se si fa tutto dal front-end non si sa che dba incompetente accidentalmente aggiornato tutti gli ordini dei clienti allo stesso cliente. Non posso sostenere con nulla, tranne trigger per il controllo come si perde una buona parte del motivo per cui è necessario il controllo, in primo luogo.

Answer 5

Utilizzo di intercettori di Hibernate per eseguire I registri di controllo è profondamente sbagliata. Sono sbalordito dal numero di blog che raccomandano questo metodo senza ricordare la sua più evidente difetto - l'intercettore deve utilizzare una nuova transazione per registrare l'audit. Il che significa che si potrebbe risparmiare con successo la transazione principale e hanno un crash di sistema che non riesce a registrare la transazione di revisione!

Answer 6

una vecchia questione che mi imbattei now.There è un'opzione più disponibile e che è Envers che è disponibile con Hibernate a partire da ver 3.6 in poi ..