ADO.NET e C#
Hal
sono arrivato al capitolo ADO.NET con C# 2008
benche' da visuale è possibile impostare un dataset con datagrid, ho
come l'impressione che utilizzando solo gli strumenti visuali sia un po'
limitativo....
voi come lavorate di solito?
Grazie per i consigli.
Buon lavoro
Raffaele Rialdi [MVP]
>
> benche' da visuale è possibile impostare un dataset con datagrid, ho come
> l'impressione che utilizzando solo gli strumenti visuali sia un po'
> limitativo....
>
> voi come lavorate di solito?
Concordo, lo strumento visuale è genericamente adatto agli scenari RAD,
cioè applicazioni che non arrivano a una versione 2.
Dai wizard però si impara. Loro generano codice, tu lo guardi e capisci
cosa fanno. Da qui puoi partire e fare due cose:
- scrivere da zero il tuo codice sulla falsa riga di quello che ha
generato il wizard
- estendere le partial class generate dal wizard, superando così alcuni
dei limiti.
Tieni presente che lo stesso Dataset è indicato per scenari RAD. In una
applicazione non RAD io non uso mai un Dataset ma mi costruisco un
object model mio.
Se vuoi vedere questo aspetto e passare al "lato oscuro" :) puoi
leggere il documento che ho pubblicato nella home page della mia
collection:
http://www.codeplex.com/rafcollection
La rafcollection consiste in una collection che offre molte delle
caratteristiche del dataset (acceptchanges, rejectchanges, ...) ma con
le tue classi per i motivi detti sopra.
Perseguendo questa strada non hai più il supporto del dataadapter
quindi le alternative per il caricamento dei dati e l'aggiornamento del
db sono:
- fare tutto a manina
- usare un OR/M
- usare Linq2SQL ... io preferisco questa strada.
Mi fermo se no sbrodolo in un discorso per cui ci vuole una giornata :)
--
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
Hal
grazie!
p.s. utilizzando mysql non è possibile utilizzare la creazione guidata
origine dati e dataset?
buon lavoro!
Raffaele Rialdi [MVP]
Prego :)
> p.s. utilizzando mysql non è possibile utilizzare la creazione guidata
> origine dati e dataset?
Non è previsto ... credo che le differenze nel modo di recuperare lo
schema rendano incompatibile il wizard con altri db.
BTW, occhio che mysql non è free. Firebird, SQL Compact e SQL Express
lo sono.
>
> buon lavoro!
Anche a te, ciao
Andrea Laforgia
<malta@n0spam_vevy.com> wrote:
>Concordo, lo strumento visuale è genericamente adatto agli scenari RAD,
>cioè applicazioni che non arrivano a una versione 2.
Raffaele, perché questi teoremi? Io sviluppo con sistemi RAD da una
vita (Delphi in particolare) e le mie applicazioni hanno superato da
molto tempo la versione 2.0. Dipende tutto da quanto potente è il
sistema di sviluppo rapido che hai a disposizione. Delphi in
particolare è *molto* potente.
>Dai wizard però si impara. Loro generano codice
Fermo, fermo, fermo. RAD e Wizard non significano necessariamente la
stessa cosa. Vedere un RAD come generatore di codice è limitativo e a
volte anche sbagliato.
>- usare un OR/M
brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr....
Hal
scusate che vor di' OR/M?
grazie
Andrea Laforgia
>scusate che vor di' OR/M?
Object-Relational-Mapping.
Raffaele Rialdi [MVP]
>> Concordo, lo strumento visuale è genericamente adatto agli scenari RAD,
>> cioè applicazioni che non arrivano a una versione 2.
>
> Raffaele, perché questi teoremi? Io sviluppo con sistemi RAD da una
> vita (Delphi in particolare) e le mie applicazioni hanno superato da
> molto tempo la versione 2.0. Dipende tutto da quanto potente è il
> sistema di sviluppo rapido che hai a disposizione. Delphi in
> particolare è *molto* potente.
Perché lo sviluppo RAD fornisce delle scorciatoie che non consentono di
*modellare* una architettura nel modo più appropriato.
Purtroppo anche gli stessi design pattern non sono generalizzabili e
vanno usati con attenzione e applicati con le opportune modifiche del
caso.
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.
OOP ci insegna che è necessario osservare un problema, e modellare una
sua rappresentazione con del codice, incapsulando lo stato ed esponendo
dei comportamenti. Quando si modella un object model si ottiene un
*grafo* che è ben lontano da assomigliare a strutture ad albero oppure
a tabelle.
Tutto questo è certamente uno sbattimento. Se non vai oltre la v1
probabilmente non ne vale neppure la pena perché il ciclo di vita di
manutenzione del software si interrompe precocemente.
Se invece vai oltre, i vantaggi durante tutte le fasi del ciclo di vita
sono così macroscopiche da recuperare abbondantemente il tempo speso
per manutenibilità, estendibilità ma anche per performance.
Io ho provato entrambe le strade per poter giudicare con la mia testa.
E anche i progetti di altri colleghi che analizziamo spesso nelle
conferenze come l'ultimo www.communitydays.it è assolutamente in linea
con quanto ho scritto.
>
>> Dai wizard però si impara. Loro generano codice
>
> Fermo, fermo, fermo. RAD e Wizard non significano necessariamente la
> stessa cosa. Vedere un RAD come generatore di codice è limitativo e a
> volte anche sbagliato.
Hal però faceva riferimento a una particolare azione del wizard di
vs.net, e a questo io mi sono riferito. Quei wizard sono usati per fare
sviluppo rad.
Forse intendiamo cose differenti.
Vs.net è uno _strumento_ Rad ma il _rad development_ è altra cosa.
Altrimenti con vs.net potremmo solo sviluppare rad il che non è
ovviamente vero.
>> - usare un OR/M
>
> brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr....
Tutti i più grossi progetti enterprise usano gli OR/M.
eBay si è scritto il proprio OR/M.
Hibernate (java) e nHibernate (.net) sono forse i più famosi ma ce ne
sono dozzine di altri e tutti usati in progetti di enorme successo.
Il successo degli OR/M è un dato di fatto supportato da architetture
vincenti, non opinioni o preferenze.
Parlo senza polemiche, si intende :)
Andrea Laforgia
> 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.
> 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). 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. Secondo me
gli ORM costringono a una visione dei dati che a volte può essere troppo
"ingessata".
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
Raffaele Rialdi [MVP]
>> *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.