Re: ADO.NET e C#

>> Perché lo sviluppo RAD fornisce delle scorciatoie che non consentono di
>> *modellare* una architettura nel modo più appropriato.
>
> Con tutto il rispetto, secondo me non è affatto vero. Ripeto: io ho
> scritto decine di sistemi con strumenti RAD che mi hanno consentito di
> modellare in modo preciso ed appropriato. Scusa, ma i tuoi mi sembrano
> giudizi un po' troppo frettolosi e superficiali o forse basati su una
> visione parziale delle cose.

Che tu ottenga il risultato desiderato, non ho dubbi.
Che la modellazione ad-hoc sian meno puntuale rispetto agli oggetti
pronti che lo sviluppo rad offre è una contraddizione in termini.
Ma ripeto che non dubito che tu riesca, in determinate condizioni e per
certe applicazioni, ad ottenere i risultati voluti.

>
>> Il dataset, tipica classe da sviluppo rad nato in casa Borland (per chi
>> ci legge e non lo sapesse, Hejlsberg viveva in casa Borland prima di
>> entrare in MS e inventare C#) è un bell'oggetto ma rappresenta i dati
>> in modo tabellare, cioè come un in-memory database, cosa molto lontana
>> dai principi di design di OOP.
>
> Non è detto che i principi di design di OOP siano i migliori quando si ha
> a che fare con i dati e difatti in moltissimi preferiscono non passare per
> degli ORM (esiste una grande massa di persone che critica questo
> approccio, vedi la object-relational impedance mismatch).

I principi di OOP non sono necessariamente i migliori in senso
assoluto. Ma quando usi linguaggi, tecnologie e librerie che sono nate
per l'OOP devono essere sfruttati in quel modo per trarne i maggiori
benefici.

Poi domani scopriremo nuove strade per l'AOP che risolvono i problemi
attuali e migreremo verso nuove piattaforme, ma ad oggi OOP è quello
che fornisce i risultati migliori.

> Quello che dici
> nel tuo messaggio e cioè che tutti i progetti di successo usano ORM non
> significa nulla. Bisogna vedere se sono divenuti progetti di successo
> *grazie* agli ORM e secondo me non è così; E' l'idea alla base a farne
> progetti di successo, non lo strumento specifico utilizzato.

Qui trovi un post che ho fatto 2006 su eBay:
http://blogs.ugidotnet.org/raffaele/archive/2006/12/29/63835.aspx
Nel link che porta all'architettura di eBay trovi anche le motivazioni
che hanno portato a questa soluzione come l'unica possibile dopo le
esperienze precedenti.

Di mio posso dire di aver sviluppato delle applicazioni sia usando il
dataset che un object model ad-hoc, proprio per comparare i risultati.
I vantaggi dell'object model si sono rivelati schiacchianti. Non per
questo biasimo chi lo usa quando sviluppa applicazioni rad dove ha
senso per tirare su velocemente una applicazione che deve, ad esempio,
trasferire o modificare dei dati.

Ho anche fatto delle prove di performance e di carico dati che ho
pubblicato in una sessione su DataSet vs Custom Collection alla WPC del
2006. Inutile dire che la soluzione custom è notevolmente più
performante.


> Secondo me
> gli ORM costringono a una visione dei dati che a volte può essere troppo
> "ingessata".

La pluggabilità dell'applicazione si sposa fantasticamente con le
metodologie a cui faccio riferimento.
Ai Community Days uno dei punti centrali è stata la discussione sui
framework di IoC (http://en.wikipedia.org/wiki/Inversion_of_control)
che danno una estrema flessibilità (pipeline, addin, ...).
Mi spiace ma l'ingessatura dipende solo da chi progetta e non dalla
metodologia.

--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele