Utilizzeresti AOP per la gestione delle transazioni del database?

Question

Qualche tempo fa ho scritto un'applicazione che utilizzava Spring AOP per definire quali metodi erano transazionali. Ora sto ripensandoci su quanto sia stata un'ottima idea; Sono stato colpito alcune volte dopo un refactor minore (modifica delle firme dei metodi, ecc.), Che ovviamente non diventa evidente fino a quando qualcosa non va effettivamente storto (e ho un database logicamente incoerente).

Quindi sono interessato ad alcune cose:

1. Altre persone hanno deciso di tornare alla gestione esplicita delle transazioni (ad es. tramite le annotazioni @Transactional )?
2. Ci sono strumenti utili che posso usare come parte di un processo di compilazione per aiutare a identificare se qualcosa è stato "rotto"?
3. Se le persone utilizzano AOP per gestire le transazioni, quali misure stanno adottando per evitare gli errori che ho commesso?

Sto usando IntelliJ IDEA che ti permette di sfogliare i metodi decorati e rifatterà la configurazione Spring XML insieme alle modifiche al nome del metodo, ma questo non è sempre sufficiente (aggiungendo un parametro a un metodo nella il posto sbagliato può influire sull'eventualità che un aspetto venga attivato, ad esempio)

Answer 1

Attualmente sto utilizzando la gestione delle transazioni dichiarativa nei due progetti Java su cui lavoro, specificando quali metodi richiedono un ambito transazionale con l'annotazione @Transactional . A mio avviso, è un buon mix di flessibilità e robustezza: sei in grado di vedere quali metodi hanno un comportamento transazionale tramite una semplice ricerca di testo, puoi regolare manualmente gli attributi di isolamento e propagazione se necessario e la quantità aggiuntiva di digitazione è praticamente negligente .

Su uno di questi progetti, ho implementato la sicurezza / registrazione tramite aspetti e ogni tanto mi sono imbattuto negli stessi ostacoli quando hai rinominato un metodo o modificato le firme. Nel peggiore dei casi, ho perso alcuni dati di registrazione dei contratti di accesso degli utenti e, in una versione, alcuni ruoli utente non sono stati in grado di accedere a tutte le funzionalità dell'applicazione. Niente di grave, ma, per quanto riguarda le transazioni di database, penso che semplicemente non ne valga la pena, ed è meglio digitare da soli @Transactional . La primavera fa comunque la parte difficile.

Answer 2

Per quanto riguarda (1): Ho trovato @Transactonal una soluzione più pratica in tutti i progetti su cui ho lavorato negli ultimi anni. In alcuni casi molto specifici, tuttavia, ho dovuto anche utilizzare Spring AOP per consentire l'uso di più di una connessione JDBC / TransactionManager perché @Transaction è legata a un singolo gestore delle transazioni.

Per quanto riguarda (2): Detto questo, in uno scenario misto, eseguo molti test automatici per trovare il codice eventualmente rotto. Io uso SpringTransactionTransactionalJUnit4SpringContextTests / AbstractTransactionalTestNGSpringContextTests per creare i miei test. Finora è stata una soluzione molto efficace.

Answer 3

Tendo ad essere più purista, ma cerco di mantenere qualsiasi gestione delle transazioni oltre un semplice autocommit, all'interno del database stesso. La maggior parte dei database è eccellente nella gestione delle transazioni, dopo tutto, è uno dei componenti chiave di ciò che un database è destinato a fare.