jankyBlog

Che tipo di operazioni su DB deve fare un ORM?
Un ORM è uno strumento per gestire in modo automatico la persistenza di una classe,
intendendo con persistenza le 4 fondamentali operazioni CRUD.
Che poi queste operazioni di CRUD interessino un oggetto e tutte le sue eventuali collezioni magari in contesto transazionale poco cambia...sempre CRUD sono.

Quindi se ho bisogno nei miei processi di business di quelle che definisco operazioni di massa
(es ricalcolo di una colonna su tutta una tabella o calcoli con grouping, statistiche e robaccia varia),
queste NON rientrano tra le operazioni di persistenza.

Quindi uno potrebbe dire...
ok il mio ORM fa solo le CRUD...
io le compilo una volta per tutte su delle stored proc generate ad hoc nel mio DB una volta sola, e sono apposto.

e qui casca l'asino.

Caso 1:
Pensate ad un oggetto del vostro domain model in memoria che contiene 20 field tutti mappati sul DB, alcuni magari anche di tipo BLOB. Di questo oggetto dalla mia applicazione cambio solo un campo e chiedo al layer di persistenza di registrarlo.
Con le stored proc "fisse" che succederebbe? Che in ogni caso farei inutilmente il passaggio di tutti i dati. Non è ottimizzazione questa. NH con il dirty checking invece fa questi controlli e genera l'SQL necessario.

Caso 2:
Nel mio Domain model, una mia classe, aggrega altre classi al suo interno.
Per fare un caricamento anticipato quando inizializzo un oggetto uso delle SELECT che con mirabolanti capriole fanno qualche join e in unico roundtrip ho tutto in memoria. Registro la SELECT in una stored proc. Fichissimo.
Ma se voglio caricare liste di oggetti senza caricare i loro aggregati? in pratica un lazy loading (utilizzatissimo peraltro)?
In questo caso NH (e pochissimi altri) genera al volo l'SQL adatto, utilizza dei dinamic proxy sugli oggetti non caricati e il gioco è fatto. Al momento (e solo allora) in cui l'applicazione richiedera i dati non caricati verranno generate altre SQL statement.

(Ce ne sarebbero anche altri casi ma mi fermo qui!)

Controindicazioni? Ah si sento una vocina....come dici? ...Le Prestazioni?

Beh possiamo fare tutte le teorie del mondo su quanto costa (in termini prestazionali) un boxing, un cast, una introspezione in reflection, e una SELECT su DB...
oppure possiamo fare delle prove su casi d'uso reali e mettere a confronto il mondo ORM con un DAO scritto ad hoc ma ovviamente statico.

Io ho scelto quest'ultima strada, e vi assicuro che i risultati sono sorprendenti
Ma questa è un'altra storia.

Spero di aver soddisfatto la curiosità di Andrea!