Ciao, mi occupo di applicativi contabili e che hanno una logica di business molto complessa. Di solito lavoro in c# e con sql server come dbms.
Per molti anni col mio team abbiamo lavorato su un framework proprietario e che si basava sui dataset per la rappresentazione in memoria dei dati. Il riempimento del grafo della vista di ogni pagina/form ed il salvataggio era totalmente a carico del framework e quasi trasparente all'applicazione.
Ora intendiamo aggiornare la tecnologia per avvalerci di un ORM pubblico.
Stiamo quindi analizzando i software esistenti per capire come muoverci. Ho analizzato diversi ORM (tra cui NHibernate e EF ) ma c'è un'esigenza che mi sembra non coprano ed ora ve la illustro.
Abbiamo la necessità di avere un ciclo del tipo (molto sinteticamente):


begin transaction
Applica modifiche al database
interroga la logica di business
se ci sono messaggi di errore
rollback transaction
altrimenti
commit transaction

Ho omesso altre cose (i controlli di validazione prima della transazione lato cliente e server) perché quelle sono invece abbastanza semplici da implementare.
La nostra necessità è di chiamare una serie di stored procedures (la logica di business è pre-compilata in codice sql) che devono agire dopo che le modifiche sono stati applicate, ed i trigger sono scattati, ma prima della commit, perché altrimenti non avremmo modo di annullare tutto se le regole che scattano sono non ignorabili oppure sono ignorabili ma il cliente decide di non ignorarle.

Vi chiedo quindi se conoscete NHibernate o qualsiasi altro ORM di quelli più noti che consenta una personalizzazione del genere.

Vi ringrazio in anticipo.
Gaetano

Si prima applico le modifiche (senza fare la commit) quindi dopo che sono scattati i trigger che hanno eventualmente aggiornato vari totalizzatori chiamo delle sp che verificano certe situazioni utilizzando tra le altre cose anche quei totalizzatori.
La logica di business essendo molto complessa ha bisogno di questi totalizzatori perché le regole riguardano somme di righe presenti in varie tabelle e non è praticabile fare i conti prima. A parte che dovrebbero comunque essere rifatti anche dopo se fossero fatti prima.
Basti pensare al controllo se tutti gli impegni su una voce di bilancio non superano la previsione disponibile.
Nello stesso momento alcuni utenti potrebbero salvare più impegni contemporaneamente ed altri cambiare la previsione. Bisogna calcolare la previsione attuale, data dalla previsione iniziale più le variazioni, sottrarre tutti gli impegni su quella voce di bilancio e vedere se sfora. Query su decine di migliaia di righe.
Invece operando sui totalizzatori variati dai trigger le righe implicate sono pochissime.