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!

provo a mettere degli ordini di grandezza in base ai numeri che ho potuto osservare nella pratica :
- in un team di 20 persone ci sono 2 esperti di SQL (cioè 1 su 10)
- in un anno capitano 1-2 query che richiedono un tuning a mano a livello di sql

se vedessi numeri diversi ... in peggio ... a indagherei l'ORM e l'uso che ne viene fatto per vedere cosa c'è che stà andando diversamente dalle mie attese

questa euristica che ho raccolto è paragonabile a quella nel vs team che usa ORM ?

"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

:-)

@Marco

occhio che il disegno per definizione non ha una sola scelta valida, un unico modo tecnicamente valido ... ditro questa frase c'è qualcosa che non va

Se usi SqlCe non ha il (SQL) profiler ma se usi Nhibernte basta che metti
<property name="show_sql">true</property>
ed hai tutte le query fatte dall’ORM: sperimenta, verifica e... non farei mai + senza :)

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

Ma perchè io e te non siamo (quasi) mai d'accordo? :)
- Primo punto: dipende dal compilatore e dipende dall'essere umano. Anche io come te ho iniziato a scrivere codice su microcontrollori e quando sono passato dall'assembler di 68HC11 e 80186 ai primi compilatori C il risultato era sicuramente peggiore in termini di ottimizzazione pura. Ma il tempo che impiegavo a scrivere il codice si riduceva drasticamente, e la manutenibilità aumentava paurosamente, quindi "who cares"... se nel concetto di "ottimizzazione" ci mettiamo anche la produttività di chi scrive il codice, allora la faccenda è diversa.
- Secondo punto: anche qui, "migliore" è un pò forte. Se penso che i query processor dei vari DBMS commerciali dopo 40 anni di ottimizzazioni varie possono ancora "sbagliare" nello scegliere il migliore piano di esecuzione di una query a causa di condizioni a contorno particolari, direi che anche il JIT magari a volte prende delle "tranvate" :) ma che, mediamente, posso passarci sopra visti i risultati complessivi.
- Terzo punto: mi sono preparato... ma questa è un pò grossa :)
- Quarto, quinto e sesto punto: amen!
- Settimo punto: sgrunt! :)

Beh, dai.. dopo tutto siamo (quasi) d'accordo!

S.

P.S: ho letto tardi il post e non ho potuto farteli a WPC, cmq complimenti per il libro!! Aspetto copia autografata... :)

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.

@Luca: scusa ma permettimi di dubitarne. Da cosa deduci che non hanno bisogno di ottimizzazione? Dal fatto che non la fai? Dal fatto che non ti hanno mai dato problemi? Se questo il caso hai fatto dei test su quantità di dati e di richieste conteporanee realmente alte per verificarne la scalabilità?
I dbms di oggi sono molto potenti e fanno un ottimo lavoro, per questo motivo si sottovaluta il problema dell'ottimizzazione del db, che di solito viene chiesta solo quando è troppo tardi, ossia quando il problema si presenta. In questo caso però si interviene quando il problema c'è già e si cerca di riparare allo stesso, quando invece sarebbe bene evitarlo in toto visto che è possibile senza dover fare chissa quale sforzo titanico.
Poi, magari sei fortunato e lavori con sviluppatori che conoscono molto bene i DB e quindi sviluppano in modo tale da non avere problemi, ma nella mia esperienza TUTTE le applicazioni che ho visto hanno delle query che andrebbero ottimizzate. Certo, fino a che si lavora con 30 utenti contemporanei e 100.000 righe non ci sono problemi di sicuro...ma a questo punto non ci sono neanche problemi di scalabilità.....

@Davide: Parlando in generale, forse la qualità media del codice SQL scritto a mano è così bassa che un qualsiasi ORM è in grado di fare meglio, per cui da fuori sembra che il risultato sia una grande ottimizzazione? :-)
Si sta presto a scoprirlo, basterebbe vedere le query che ora ci si può inventare con LINQ per interrogare a mo di SQL gli oggetti della nostra applicazione, se prima si scriveva male l'SQL riferito al RDBMS, è difficile che il risultato cambi lato applicativo. Cosa neanche tanto disastrosa visto che in questo modo il presunto collo di bottiglia non sarà più il RDBMS (o almeno non solo lui) ma anche gli strati sopra che applicheranno LINQ in modo fantasioso, ma almeno quando succederà non si potrà più dare la colpa all'RDBMS e gli "altarini" si scopriranno... :-D