O/RM: falsi miti vs. cruda realtà

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:

posted @ mercoledì 10 dicembre 2008 13:23

Print

Comments on this entry:

# Re: O/RM: falsi miti vs cruda realta;

Left by Mauro Servienti at 10/12/2008 13:46
Gravatar
Ciao,

* il punto 1 mi piace perchè tra parentesi c'è la parola "buon" ;-)
* per il resto non c'è nulla da eccepire, anzi.

mi permetto una sola considerazione. ci sono uomini bravi e meno bravi, come ci sono team bravi e meno bravi ci sono anche situazioni in cui scriversi un ORM potrebbe avere senso, sottolineo potrebbe, del resto se un uomo ha scritto un compilatore o se un uomo ha scritto NH non vedo dove stia il problema... l'unico problema è solo se il gioco vale la candela o se ci sono circostanze che mi obbligano a farlo nonostante il gioco non valga la candela.

.m

# re: O/RM: falsi miti vs cruda realta;

Left by Mario Duzioni at 10/12/2008 14:20
Gravatar
NO NO NO, assolutamente NO!

Non sono assolutamente d'accordo: non voglio neanche minimamente credere al fatto che Babbo Natale non esista! :-p

Scherzi a parte, mi meraviglia che qualcuno possa obiettare su qualche punto tra questi... :-/

Ciao!

# re: O/RM: falsi miti vs. cruda realtà

Left by Marco De Sanctis at 10/12/2008 16:05
Gravatar
"Un O/RM è (attualmente) l'unico modo tecnicamente sensato per persistere un Domain Model."

Fico, io lo dico/scrivo almeno da 3 anni :)

# re: O/RM: falsi miti vs. cruda realtà

Left by raffaeu at 10/12/2008 16:20
Gravatar
Andrea mi sorge il dubbio che:
A) Hai letto un qualche blog che polemizzava su ORM
B) Ti sei fermato un' altra volta alla macchinetta del caffe' con il reparto IT dove fai consulenza
C) Hai letto qualche post della concorrenza

:-)

# re: O/RM: falsi miti vs. cruda realtà

Left by Devil’s lawyer at 11/12/2008 16:15
Gravatar
- Vero, ma dato che esistono ancora i programmatori si può affermare con ragionevole certezza che questa affermazione ha dei limiti.
Un (buon) compilatore, scritto da un (ottimo) programmatore (e pertanto umano) produrrà “sempre” un codice ottimizzo limitatamente alla conoscenza che gli è stata fornita dell’ambiente di partenza e di destinazione, se così non fosse la macchina di Turing sarebbe realtà.
- Ancora molto vero, ad un compilatore JIT è stata ampliata la conoscenza dell’ambiente con informazioni di runtime, cosa che gli permette di produrre codice più ottimizzato.
Ricordiamoci però cosa si diceva dei compilati VB6, i concetti alla base della compilazione JIT non mi sembrano molto lontani da quelli del runtime di VB6.
Inoltre non credo che i benefici portati dal CLR si limitino al compilatore JIT.
- Sebbene per la seconda affermazione non credo esista una dimostrazione vagamente scientifica come per la prima, forse è il caso di pensare se un O/RM non faccia più di quanto sia veramente utile. In Object, Relational e Mapping non trovo query, SQL o qualsiasi altra parola si possa intendere interrogazione e/o manipolazione di dati.
- La colpa è dell’O/RM dal momento stesso in cui mette a disposizione strumenti di bassa qualità, soprattutto se questi strumenti sono la via preferenziale per ottenere il risultato desiderato.
- Ma quanto è vero!!! Se penso che c’è ancora gente che concatena stringhe invece di utilizzare lo StringBuilder.
- Per dimenticare l’SQL, bisogna prima conoscerlo, non credo che l’utilizzo di questi strumenti ne favorisca l’apprendimento.
- Nessun medico ha mai prescritto neanche il web come soluzione ai problemi di distribuzione delle applicazioni … Web e Applicazione sono due parole che non sono state concepite per essere messe una vicina all’altra. Eppure …

# re: O/RM: falsi miti vs. cruda realtà

Left by Davide Mauri at 12/12/2008 02:15
Gravatar
Concordo su tutti i punti tranne il 3 ed il 7 :-)

In realtà per il settimo non è che non sia d'accordo, ma direi che non è possibile asserire che è sempre il metodo migliore. E' un metodo, cosi come un metodo alternativo può essere quello di farsi un DAL a mano....direi che il tutto dipende dal "solito" rapporto tra complessita, risorse disponibili e manutenibilità.

A parte questo però, vorrei porre l'attenzione sul terzo punto. Un OR/M è un generatore di codice SQL ma dato che SQL è un linguaggio dichiarativo basato sulla logica matematica e quindi sulle proprietà degli insiemi di dati su cui lavora, non è attualmente vero che il codice prodotto da un compilatore sia migliore di quello scritto da una persona. E non mi riferisco all'aspetto tecnico, ossia alla qualità del codice SQL, quanto all'aspetto logico, ossia la soluzione vera e propria del problema.
Un linguaggio dichiarativo basato su un motore di inferenza logica (come SQL) parte dal presupposto che una volta trovata la soluzione logica basata sulle caratteristiche proprie dell'insieme dei dati su cui si opera, sia possibile esprimerla sottoforma di query che definisce le caratteristiche dell'insieme risultante, lasciando al computer il compito di trovare il migliore algoritmo risolutivo e quindi implementarlo.

Il punto però è che alcune (molte) delle proprietà che gli insiemi di dati su cui lavoriamo hanno, sono "nascoste" ossia visibili solamente perchè come esseri umani possiamo effettuare una serie di deduzioni basate sul significato dei dati che abbiamo, cosa che - ovviamente - una macchina non può fare in quanto per essa i dati non hanno un significato. Avevo mostrato questa cosa proprio alla sessione che feci con Janky sugli OR/M ad UgiDotNet, mostrando l'enorme differenza che una richiesta semplice come controllare se un libro è in prestito oppure no nel db di gestione di una biblioteca che avevamo usato come esempio potesse essere scritta in modo molto diverso da un essere umano (io) e da un OR/M (nhibernate).

Detto ciò, se si parla solamente di persistenza quanto appena detto potrebbe avere un impatto meno importante, ma è cmq da tenere presente: per ora - a differenza di quanto avviene con i compilatori - il codice SQL (e quindi la soluzione logica che rappresenta) è fatto al meglio da un essere umano e non da un macchina. Non per bravura, ma per la compresione del significato dei dati e da qui dalla capacità di sfrutturne le caratteristiche "nascoste" o deducibili.
Comments have been closed on this topic.
«dicembre»
domlunmarmergiovensab
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789