150 messaggi dal 24 maggio 2001
Contributi
Anch'io ho trovato interessante l'articolo. Anche se (come dicevo a dino) le custom collection hanno altri vantaggi che nell'articolo non sono citati.
Poi (sempre IMHO) dopo la lettura dell'articolo, un newby è portato a scegliere i dataset per il fatto che sono molto più semplici da utilizzare.

Sugli ORM qualcosa ne so, se ne potrebbe parlare nel forum. Date un'occhiata a N-Hibernate (il più famoso) o ai BBADataObjects (sourceforge.net/projects/bbadataobject...che ho scritto io ;-))

Ciao
Mi aggiungo al coro in favoro delle custom collections.
Concordo con Emanuele per quanto riguarda i newby, anzi estendo il discorso: spesso per semplicità o pigrizia anche molti "esperti" usano i dataset. Vorrei sottolineare un aspetto importante in favore delle custom collections (o, anche più semplicemente dei custom business objects): il disaccoppiamento dalla base dati (più in generale: dal sistema di persistenza dei dati). Spesso confondere le entità con la loro persistenza porta ad errori di design considerevoli o ci costringe a salti mortali per costruire le dipendenze (rischiando di incappare in quelle circolari!). Microsoft ci ha abituati un po' troppo bene, preparandoci tutto già pronto (ricordo demo di progetti master/details fatte solo a colpi di mouse!) ma, seppur rispettando gli obiettivi di MS, ritengo che non sia l'approccio migliore ad una tecnologia complessa, potente ed object-oriented come .NET. I colleghi Java sono stati costretti ad usare meglio la loro piattaforma e forse è stato per loro un bene (anche se esistono sviluppatori J2EE che di Enterprise hanno solo il nome  )

Quanto agli ORM: sicuramente vale la pena prenderli in considerazione o, almeno, avere idea di quello che sono, di quello che possono o non possono fare. NHibernate è il più noto ed, essendo un porting del consolidato Hibernate per Java, probabilmente anche il più testato, completo e stabile.
Il progetto di Emanuele è molto carino e di certo è un buon punto di partenza per approcciare gli ORM (partire da NHibernate è parecchio più complesso...).

Un'ultima considerazione sugli ORM: belli, potenti, fanno risparmiare tempo, scrivono per noi il codice ripetitivo e noiso ma... non bastano!
Alla fine manca sempre la parte vera della nostra applicazione: la business logic (rif. 3-tier o n-tier)! E per quella non c'è automatismo che si possa sostituire al programmatore.

Avrei tanto altro da dire ma mi sa che mi sono dilungato un po' troppo... Scusate.

Matteo Casati
GURU4.net
non sono d'accordo sul fatto che il DataSet sia il male sceso in terra.
fermo restando che sono d'accordo che una custom entity sia decisamente migliore da qualsiasi punto di vista la si guardi, ci sono decine e decine di esempi che mi vengono in mente in cui, semplicemente, usare un DataSet (tipizzato) o una custom entity non cambia di una virgola l'ambito in cui si opera.

quanto alle demo, spesso si usano i DataSet per un solo e semplice motivo: le platee sono fatte da gente che non è esperta, una entity ha quasi sempre l'effetto su questo target di disorientarle. e se li perdi per strada, come speaker non hai fatto il tuo dovere.

insomma, è come sempre questione di trovare un giusto bilanciamento nelle cose che si fa

fermo restando che gli O/R mapper non mi piacciono neanche un po'

Daniele Bochicchio | ASPItalia.com | Libri
Chief Digital Officer@icubed | Chief Innovation Officer@openloop
Microsoft Regional Director, MV
Il fatto è che non bisogna estremizzare. I DataSet vanno bene in certi contesti, come del resto Dino stesso ha rilevato nell'articolo da cui ha preso spunto questo thread.

E' però sbagliato usarli sempre e comunque, perchè sono oggetti intrinsecamente duttili e generali (per cui sono pensati per contenere una serie di oggetti e informazioni che non sempre e comunque vanno bene). La loro valenza non è tanto di rappresentazione, quanto di contenimento. Non si può pensare di rappresentare la struttura degli oggetti di business nell'ambito di un DataSet tramite le relazioni. Non si può pensare ai DataSet come al modello sui cui basare la logica applicativa. E i DataSet tipizzati non sono una risposta in questo senso.

L'alternativa sono oggetti custom, magari serializzabili, ma in ogni caso leggeri e finalizzati a contenere solo ciò che serve, sfruttando al tempo stesso la tipizzazione stretta.

Ciao, Ricky.

Ing. Riccardo Golia
Microsoft MVP ASP.NET/IIS
ASPItalia.com Content Manager
http://blogs.aspitalia.com/rickyvr
http://ricky.aspitalia.com
http://www.riccardogolia.it
rickyvr [Staff] wrote:
E i DataSet tipizzati non sono una risposta in questo senso.

no, ma sono una scelta non meno valida, imho, di custom entities quando la
complessità di un'applicazione è bassa.
insomma, se devo fare una semplice applicazione web che mostra due dati in
croce e non ha bisogno di scalare all'infinito, io non mi vergono a dirlo ma
li uso eccome
anche se poi, in realtà, preferisco utilizzare DataTable.
ovviamente se la complessità sale il problema di cosa scegliere non si pone
nemmeno

Daniele Bochicchio | ASPItalia.com | Libri
Chief Digital Officer@icubed | Chief Innovation Officer@openloop
Microsoft Regional Director, MV
Ok, ho dato un'occhiata in giro e in effetti gli O/R mapper non mi esaltano, lo ammetto; il problema imho è che c'è una spaccatura tra i livelli di un'applicazione: da una parte la programmazione ad oggetti, dall'altra la persistenza secondo il modello relazionale... entrambe hanno dei pregi ai quali è dificile rinunciare, ma comunque bisogna sempre scrivere molto codice per rendere persistenti gli oggetti.

Io già nel '95 ho usato un DBMS orientato agli oggetti, ma ad oggi sembrano scomparsi o comunque riservati ad un ambito aziendale di alto livello: sarebbe interessante avere caratteristiche di persistenza OO in un DB come SQL Server o simili...
Due considerazioni per Daniele:

1) con "demo fatte a colpi di mouse" non mi riferivo solo ai dataset ma ad una serie di cose. Ad ogni modo non credo nei wizard (si vedano le demo su VS2005, tanto ad effetto quanto inutili in progetti veri che siano più complessi della rubrica del telefono!)
Ok, le platee non sono fatte solo da esperti. Ma allora perché non differenziare gli eventi? Penso all'ultimo workshop cui ho partecipato (Component Development, organizzato da UGIdotNET, il 14/07/2005, c/o Microsoft): il nome altisonante non ci prendeva molto con le sessioni (quelle della mattina) dove hanno mostrato come... creare un controllo (poteva andare bene 3 anni fa, non adesso!). Tolti gli interventi di Fabio (Santini) e di Andrea (Saltarello)... avrei fatto meglio a stare a casa! Ditelo prima, almeno mi attrezzo (iPod, GameBoy, ecc.)

2) odi gli ORM? Tendenzialmente anch'io (dalla mia esperienza: a conti fatti ti costringono a scrivere più codice. Vanno bene solo in team grandi e non omogenei in fatto di competenze). Ti faccio però una domanda: un DataSet tipizzato non è, stringi stringi, anch'esso un ORM?

Matteo Casati
GURU4.net
m.casati wrote:

1) con "demo fatte a colpi di mouse" non mi riferivo solo ai dataset ma ad
una serie di cose. Ad ogni modo non credo nei wizard (si vedano le demo su
VS2005, tanto ad effetto quanto inutili in progetti veri che siano più
complessi della rubrica del telefono!)

che non ci crediamo io, te e qualche altro non cambia di una virgola quanto
ho detto: al mondo, purtroppo, non si fanno solo progetti enterprise.
e, credimi, l'utente medio pur lavorando con una tecnologia ne conosce al
massimo il 2%.

Ditelo prima, almeno mi attrezzo (iPod, GameBoy, ecc.)

non avendo seguito non posso certo commentare, ma lasciami dire che è
normale che sia così. ancora una volta, gli eventi si fanno soprattutto per
chi non conosce la tecnologia. tu sei già sulla "barca", non ti si deve
convincere che quello che hai fatto per anni fa schifo e devi passare a
qualcosa di nuovo. vai agli eventi con questo concetto marchiato nella mente
(e col gameboy  ) e vedrai che seguirai sì meno cose, ma quelle che ti
interessano davvero.

2) odi gli ORM? Tendenzialmente anch'io (dalla mia esperienza: a conti
fatti ti costringono a scrivere più codice. Vanno bene solo in team grandi
e non omogenei in fatto di competenze). Ti faccio però una domanda: un
DataSet tipizzato non è, stringi stringi, anch'esso un ORM?

beh, decisamente no. gli O/R mapper fanno un lavoro in automatico, in
moltissimi casi, mentre per creare un DataSet tipizzato il lavoro lo fai tu
sviluppatore.
ripeto, ci sono casi in cui, semplicemente, un DataSet non è il male sceso
in terra.
fermo restando che anche io preferisco le entities, tutta la vita.

Daniele Bochicchio | ASPItalia.com | Libri
Chief Digital Officer@icubed | Chief Innovation Officer@openloop
Microsoft Regional Director, MV

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.