StrangeLog - Il blog di Andrea Saltarello - mercoledì 10 dicembre 2008 Entries

Pensieri in libertà:

Un (buon) compilatore produrrà "sempre" un codice maggiormente ottimizzato in confronto a quello prodotto da un essere umano, altrimenti io lavorerei ancora in assembly su workstation RISC.
Un compilatore JIT ha la possibilità di produrre il codice migliore date le condizioni di runtime. Non sei d'accordo? No problem: smetti di usare .NET/il CLR <g>
Preparati: Babbo Natale non esiste e un O/RM è (anche) un compilatore JIT di codice SQL. Ora fai un sospirone e rileggi i punti precedenti :-)
Se il codice [HQL|LINQ|OQL|VattelapescaQueryLanaguage] di partenza (o il mapping) è di bassa qualità non serve un compilatore bensì San Gennaro (o equivalente), quindi la "colpa" non è dell'O/RM
Non lamentarti se un O/RM "è lento" se non hai impostato il fetch plan coerentemente al caso d'uso degli oggetti: è l'equivalente di un "SELECT * FROM Tabella" senza selezione delle colonne e senza filtri. Dovrebbe essere veloce?
Gli O/RM *non servono* per dimenticare SQL. Conosci il detto "il (SQL) profiler è il miglior amico dell'uomo"? Bene: sperimenta, verifica e... Rileggi il punto precedente
Un O/RM è (attualmente) l'unico modo tecnicamente sensato per persistere un Domain Model. Che mi risulti, però, nessun medico ha mai prescritto l'uso di Domain Model e/o O/RM

Technorati Tag: ORM