Web Log di Raffaele Rialdi

# re: La rivolta contro i dataset

Disclaimer: sono un fan dei typed dataset
Non ho seguito il tuo workshop, vorrei capire se tu distingui la versione typed e untyped dei dataset.
Nei progetti in cui sono coinvolto solitamente l'80% del lavoro è portarsi in giro dei dati, eventualmente elaborarli e visualizzarli (browser).
Attualmente usiamo ADO, per cui recordset su cui lavoriamo ciclando con la movenext e accedendo alle colonne.
Dal mio punto di vista i typed dataset semplificano questo utilizzo, permettendo di avere anche le informazioni sulla struttura dei dati, permettendone la tipizzazione.

Dal mio punto di vista le feature di update/insert/delete sono marginali relative ad un sottoinsieme di quel 20% che rimane. Un sottoinsieme in quanto molte volte le modifiche vanno su insiemi limitati di dati (spesso un solo record) per cui l'approccio delle entity class va bene.

Il problema serio che stò vedendo con asp.net 2.0 è che, fino alla ctp di marzo, gestire i typed dataset è un incubo (creazione ottenuta tramite trucci, gestione connection string inutilizzabile, databinding che non usa la tipizzazione dei dataset)

# re: La rivolta contro i dataset

Carlo, peccato che non fossi presente e se sei presente Giovedi possiamo discutere durante una pausa di questo argomento.
I dataset li trovo molto indicati per progetti semplici laddove i dati possono essere strutturati in modo semplice.

Se guardo però ad un problema complesso, la prima cosa da fare è trovare un object model che rappresenti in modo adeguato il problema secondo i principi dell'OOP. In questo caso raramente riesco a rappresentare i problemi in modo tabulare (righe e colonne) e le datarelation mi vanno decisamente strette per stabilire il rapporto con i dati.

Preferisco quindi pensare ad un object model che soddisfi pienamente la logica del problema costruendo delle custom entities e delle collection che facciano da collante tra i vari oggetti.

Per questo motivo non faccio differenza tra typed e untyped. Certamente i typed dataset hanno molti vantaggi rispetto agli untyped ma soffrono comunque del problema descritto.

Se poi fai delle prove, vedrai che i dataset (proprio perchè generici) hanno un overhead che causa delle grosse perdite di performance che in alcuni casi (progetti medio-grandi per l'appunto) non sono da sottovalutare.

Purtroppo in qualche parola non si può descrivere tutto ma se ci sarai Giovedi potremmo chiaccherarne in una delle pause.

Ciao!

# re: La rivolta contro i dataset

So che Balena e Di Mauro "tifano" per i dataset. Ho avuto modo di parlarne soprattutto con Di Mauro che mi aveva detto in WPC che il motivo principale fosse l'eccesso di complessità nel costruire la collection che supportasse tutte le feature del dataset.

La difficoltà è infatti tanta e ma personalmente la ritengo di secondo piano perchè lo sforzo lo fai una volta sola. Io infatti mi sono creato un generatore di collection strong-typed che implementa tutte le interfacce necessarie a supportare le feature che sono esposte anche dal dataset.
Inoltre tieni conto che per il mondo asp.net le interfacce più complesse sono poco utili (IBindingList è praticamente inutile, mentre ITypedList può servire solo al design time).

Per semplicità la collection che ho mostrato nella mia sessione è stata sfoltita di alcune cose ma non è un task complesso completarla. Le cose più difficili sono nel codice che ho proposto in sessione.

I risultati del benchmark sono nelle mie slide e sono notevoli:
- Custom Entities 44secondi contro DataSet 1minuto e 9secondi
- I dataset impiegano il 57% del tempo in più rispetto alle custom entities
o se preferisci
- Le custom entities impiegano il 36% in meno rispetto al dataset

Per l'HIP devo chiedere ... anch'io ho problemi. Credo di sapere dov'è il problema.

# re: La rivolta contro i dataset

Ciao Marco,
in una sessione di 1h15 non si può dire più di tanto e chi era presente credo possa dirti che ero al limite della "sopportabilità" ;-)

Sono un fan delle collection tipizzate e già ai tempi di COM ne ho costruita una in ATL (che faceva uso smodato di template annidati) proprio per costruire dei complessi object model tipizzati (si, sono un patito di strong-typing da sempre e ho sempre odiato il variant).

In dotnet le cose si sono semplificate tantissimo ma nonostante questo, ed in assenza (nella 1.1) dei generics, la fatica è ancora consistente se vuoi avere collection che supportino tutte le belle cose che fa il dataset (che è scritto splendidamente bene).

Una volta arrivato ad una collection che mi ha dato soddisfazione ho avuto ovviamente due esigenze:
- la necessità di replicare enne volte lo stesso codice per tutte le collection di cui avevo bisogno
- la necessità di poter rigenerare tutte le collection anche a progetto già in stato avanzato
A questo scopo mi sono scritto un tool che genera per ogni collection due classi: una astratta che fa il grosso, una concreta (che deriva dalla precedente) che non cambierà mai.
In questo modo ottengo di poter rigenerare quando voglio tutte le collection nel caso voglia modificare, fare un fix, o altro nelle collection. E d'altro canto quelle concrete conterranno invece le proprietà e i metodi delle collection specifici delle custom entities tipizzate.

Ovviamente in sessione non c'era tempo di parlare anche di questo e così ho semplificato il listato della collection e ho evitato di mostrare il tool.

Quando avrò più tempo preparerò altro materiale su questi argomenti e magari qualche articolo.

P.S. non sei l'unico non umano ;-)

# re: La rivolta contro i dataset

Grazie mille, chiaro e completo come sempre :) per motivi di tempo mi trovvo spesso a utilizzare DataSet ma adesso che ho un pò di respiro mi guardavo in torno e il sistema che adotti e la tua soluzione mi è piaciuta davvero.

apettiamo un articolo per entrare nel dettaglio :)

# re: La rivolta contro i dataset

Prego! Spero ci sia l'occasione dell'articolo ;-)

# re: La rivolta contro i dataset

Ciao Carlo,
nel caso di web services la differenza sta nel fatto che le custom entities devono essere presenti anche sul client. Per il resto sia custom entities che collection sono facilmente serializzabili e infatti le sto usando con remoting in modo più che soddisfacente sia con il formatter soap che binario.

Una precisazione è d'obbligo. I web services hanno senso solo se hai uno scenario che non è puro dotnet. Se invece tutti i client sono dotnet ha molto più senso remoting in quanto la ricchezza del contratto dotnet è di gran lunga superiore a quella wsdl che, proprio per offrire eterogeneità dei sistemi operativi dei client, deve essere più povera.

Concludendo la risposta è che si può anche con i WS. La mia collection internamente usa ArrayList e quindi viene serializzata questa ma se vuoi cambiare il modo in cui è rappresentata puoi farlo facilmente implementando ISerializable.

Tanto per darti un idea ecco una collection vuota di Customer serializzata con il formatter soap su file:

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:clr="http://schemas.microsoft.com/soap/encoding/clr/1.0" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<a1:CustomerCollection id="ref-1" xmlns:a1="http://schemas.microsoft.com/clr/nsassem/Test/Test%2C%20Version%3D1.0.1916.30593%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull">
<site xsi:null="1" />
<coll href="#ref-4" />
<_OnListChanged xsi:null="1" />
<_IsSorted>false</_IsSorted>
<_ListSortDirection>Ascending</_ListSortDirection>
</a1:CustomerCollection>
<a3:ArrayList id="ref-4" xmlns:a3="http://schemas.microsoft.com/clr/ns/System.Collections">
<_items href="#ref-5" />
<_size>0</_size>
<_version>0</_version>
</a3:ArrayList>
<SOAP-ENC:Array id="ref-5" SOAP-ENC:arrayType="xsd:anyType[16]" />
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

# re: La rivolta contro i dataset

Ciao Raffaele,
quindi il criterio di ricerca è "cablato" nella firma del metodo:
Ad esempio
SelectByID
SelectByDesc
...
...
io pensavo ad implementare un generico Select che accetta come parametro l'istanza di una classe che espone un metodo che si occupa (quanti "che" :-))
di eseguire il confronto.... una specie di IComparator
Il problema è il dover implementare un Comparator diverso per ogni criterio ...

# re: La rivolta contro i dataset

Ciao Roberto, generalizzare ha pregi ma anche difetti. Se hai effettivamente tanti metodi che sono analoghi per modalità di ricerca puoi fare anche come dici tu ma non è più strong-typed e puoi anche perdere in efficienza.
La soluzione più generica è ovviamente quella che usa reflection ma qui ovviamente hai le performance peggiori.
Se poi ci sono dei value type puoi avere la penalizzazione di box/unbox.
Devi valutare tu pregi e difetti... io preferisco avere tutto strong-typed.

(Qualcosa di meglio si potrà fare con i generics con il framework 2.0.)