StrangeLog - Il blog di Andrea Saltarello

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

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!

"Un O/RM è (attualmente) l'unico modo tecnicamente sensato per persistere un Domain Model."

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

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

:-)

- 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 …

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.