Entities vs DataSets
Ebbene sì, non posso che condividere quanto espresso da Dino nell'articolo intitolato DataSets vs. Collections presente nei giorni scorsi su MSDN Magazine:
http://msdn.microsoft.com/msdnmag/issues/05/08/CuttingEdge/default.aspx
Da leggere!
Nella stessa categoria
Emanuele DelBono scrive: 
Entities vs DataSets
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
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
m.casati scrive:
Re: Entities vs DataSets
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.
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.
Daniele Bochicchio scrive:
Re: Entities vs DataSets
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'
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'
m.alberti scrive:
Re: Entities vs DataSets
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...
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...
»»»» rickyvr scrive:
Re: Entities vs DataSets
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.
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.
m.casati scrive:
Re: Entities vs DataSets
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?
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?
Daniele Bochicchio scrive:
Re: Entities vs DataSets
rickyvr [Staff] wrote:
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
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 scrive:
Re: Entities vs DataSets
m.casati wrote:
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%.
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.
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.
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.
»»»» rickyvr scrive:
Re: Entities vs DataSets
Se mi permetti, vanno distinti gli eventi promozionali da quelli formativi (DotNetCircle Days, UGIdotNET WorkShops, ecc.). Nei primi lo scopo non è quello di formare, ma di vendere... Ecco allora un proliferare di RAD e drag&drop. Io non condivido questo approccio, sarà perchè a me il codice piace scriverlo e non generarlo, ma mi rendo anche conto che per la maggioranza delle persone che sono presenti a quel tipo di eventi la presentazione delle funzionalità RAD centra esattamente le aspettative.
Personalmente sto preparando un progetto da utilizzare in uno dei prossimi eventi DotNetCircle e credimi se ti dico che uno dei problemi principali è stato quello di scegliere la tipologia dell'applicazione, l'architettura e i contenuti. Gli eventi in generale vanno mirati al target a cui si rivolgono perchè devono essere formativi. Avere cinque persone su trecento che ti seguono durante l'evento non è il massimo, anzi è rischioso... Inserire troppa complessità non permette di gestire al meglio gli obiettivi formativi e di comunicazione propri di un evento pubblico a cui partecipano tante persone di tutti i tipi. Inoltre l'eccessiva complessità presuppone di dover dare per scontate un sacco di cose. Per questo motivo gli eventi in generale sono caratterizzati da sessioni diverse con un grado di difficoltà diverso, orientate ad un utenza con aspettative e capacità differenti. Fare eventi gratuiti mirati solo agli esperti non riempie le sale!
Io a quell'evento c'ero e sono in generale a tutti gli eventi della Community MSDN italiana, visto che poi mi diverto a fare un po 'di foto. Secondo me la chiave di interpretazione per quanto riguarda gli eventi è questa... Gli eventi hanno una triplice valenza:
1) sono una occasione formativa, dove non tutto (si spera, .NET è una tecnologia che ha più di tre anni), ma forse alcune cose possono risultare nuove o poco conosciute e quindi diventa possibile imparare qualcosa in più (c'è sempre da imparare da tutti);
2) sono una occasione di confronto: è assolutamente vero che le soluzioni proposte non sempre sono le migliori, ma proprio qui sta il punto secondo me. Cosa ci permette di sapere che una soluzione è meglio di un'altra e quindi avere una opinione? Cosa ci fa capire che stiamo lavorando bene? Cosa ci permette di conoscere a che punto stiamo? Ecco allora che gli eventi ci posso aiutare per capire quale è il nostro grado di preparazione, quali sono i punti di forza personali e le aree di miglioramento. Il confronto si ha solamente ascoltando cosa hanno da proporre gli altri, studiare libri e manuali, fare lab personale chiusi nella propria "cantina" non è sufficiente secondo me. Arriva il momento prima o poi del confronto e gli eventi sono l'occasione giusta;
3) sono una occasione di incontro fantastica: io sfrutto gli eventi per incontare persone e amici. Ti assicuro che da questi incontri ne esco sempre arricchito. Se una sessione non mi interessa perchè di tipo primer trovo dell'altro da fare, in genere mi fermo in corridoio a parlare con gli amici, sia di tecnologia e lavoro, sia di altro.
Ecco perchè io non considero la partecipazione agli eventi "tempo perso" e... il lettore MP3 lo lascio sempre a casa (la macchina digitale invece me la porto dietro).
Ci stiamo lavorando. Parleremo anche di entities e non solo.
Ciao, Ricky.
Modificato da rickyvr il 12 agosto 2005 15.38 -
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...
Se mi permetti, vanno distinti gli eventi promozionali da quelli formativi (DotNetCircle Days, UGIdotNET WorkShops, ecc.). Nei primi lo scopo non è quello di formare, ma di vendere... Ecco allora un proliferare di RAD e drag&drop. Io non condivido questo approccio, sarà perchè a me il codice piace scriverlo e non generarlo, ma mi rendo anche conto che per la maggioranza delle persone che sono presenti a quel tipo di eventi la presentazione delle funzionalità RAD centra esattamente le aspettative.
...(si vedano le demo su VS2005, tanto ad effetto quanto inutili in progetti veri che siano più complessi della rubrica del telefono!)
Personalmente sto preparando un progetto da utilizzare in uno dei prossimi eventi DotNetCircle e credimi se ti dico che uno dei problemi principali è stato quello di scegliere la tipologia dell'applicazione, l'architettura e i contenuti. Gli eventi in generale vanno mirati al target a cui si rivolgono perchè devono essere formativi. Avere cinque persone su trecento che ti seguono durante l'evento non è il massimo, anzi è rischioso... Inserire troppa complessità non permette di gestire al meglio gli obiettivi formativi e di comunicazione propri di un evento pubblico a cui partecipano tante persone di tutti i tipi. Inoltre l'eccessiva complessità presuppone di dover dare per scontate un sacco di cose. Per questo motivo gli eventi in generale sono caratterizzati da sessioni diverse con un grado di difficoltà diverso, orientate ad un utenza con aspettative e capacità differenti. Fare eventi gratuiti mirati solo agli esperti non riempie le sale!
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.)
Io a quell'evento c'ero e sono in generale a tutti gli eventi della Community MSDN italiana, visto che poi mi diverto a fare un po 'di foto. Secondo me la chiave di interpretazione per quanto riguarda gli eventi è questa... Gli eventi hanno una triplice valenza:
1) sono una occasione formativa, dove non tutto (si spera, .NET è una tecnologia che ha più di tre anni), ma forse alcune cose possono risultare nuove o poco conosciute e quindi diventa possibile imparare qualcosa in più (c'è sempre da imparare da tutti);
2) sono una occasione di confronto: è assolutamente vero che le soluzioni proposte non sempre sono le migliori, ma proprio qui sta il punto secondo me. Cosa ci permette di sapere che una soluzione è meglio di un'altra e quindi avere una opinione? Cosa ci fa capire che stiamo lavorando bene? Cosa ci permette di conoscere a che punto stiamo? Ecco allora che gli eventi ci posso aiutare per capire quale è il nostro grado di preparazione, quali sono i punti di forza personali e le aree di miglioramento. Il confronto si ha solamente ascoltando cosa hanno da proporre gli altri, studiare libri e manuali, fare lab personale chiusi nella propria "cantina" non è sufficiente secondo me. Arriva il momento prima o poi del confronto e gli eventi sono l'occasione giusta;
3) sono una occasione di incontro fantastica: io sfrutto gli eventi per incontare persone e amici. Ti assicuro che da questi incontri ne esco sempre arricchito. Se una sessione non mi interessa perchè di tipo primer trovo dell'altro da fare, in genere mi fermo in corridoio a parlare con gli amici, sia di tecnologia e lavoro, sia di altro.
Ecco perchè io non considero la partecipazione agli eventi "tempo perso" e... il lettore MP3 lo lascio sempre a casa (la macchina digitale invece me la porto dietro).
Alla fine tutto dipende... dal punto di vista con cui si guardano le cose (eventi o dataset che siano!).
A questo punto faccio una richiesta: organizzare eventi non solo per diffondere una tecnologia ma anche per usarla al meglio (o almeno un po' sopra quel 2% che hai - mi sembra correttamente - stimato).
Ci stiamo lavorando. Parleremo anche di entities e non solo.
Ciao, Ricky.
Modificato da rickyvr il 12 agosto 2005 15.38 -
m.casati scrive:
Re: Entities vs DataSets
Grazie Daniele. Preciso come sempre!
Alla fine tutto dipende... dal punto di vista con cui si guardano le cose (eventi o dataset che siano!).
A questo punto faccio una richiesta: organizzare eventi non solo per diffondere una tecnologia ma anche per usarla al meglio (o almeno un po' sopra quel 2% che hai - mi sembra correttamente - stimato).
A presto.
Grazie Daniele. Preciso come sempre!
Alla fine tutto dipende... dal punto di vista con cui si guardano le cose (eventi o dataset che siano!).
A questo punto faccio una richiesta: organizzare eventi non solo per diffondere una tecnologia ma anche per usarla al meglio (o almeno un po' sopra quel 2% che hai - mi sembra correttamente - stimato).
A presto.
ITHost scrive:
Re: Entities vs DataSets
"rickyvr [Staff]"
[snip]
hai dimenticato il 4 punto fondamentale
il pranzo/cena dopo evento
"rickyvr [Staff]"
[snip]
3) sono una occasione di incontro fantastica: io sfrutto gli eventi per
incontare persone e amici. Ti assicuro che da questi incontri ne esco
sempre arricchito. Se una sessione non mi interessa perchè di tipo primer
trovo dell'altro da fare, in genere mi fermo in corridoio a parlare con
gli
amici, sia di tecnologia e lavoro, sia di altro.
Ecco perchè io non considero la partecipazione agli eventi "tempo perso"
e... il lettore MP3 lo lascio sempre a casa (la macchina digitale invece
me
la porto dietro).
hai dimenticato il 4 punto fondamentale
il pranzo/cena dopo evento
SM15455 scrive:
Re: Entities vs DataSets
Vabbè Christian, ma allora il mangiare per te è proprio un chiodo fisso
Byez
.
Vabbè Christian, ma allora il mangiare per te è proprio un chiodo fisso
Byez
.
Daniele Bochicchio scrive:
Re: Entities vs DataSets
m.casati ha scritto:
in genere gli eventi hanno un giusto mix di argomenti semplici e complessi. le volte che mi sono trovato a palare di sicurezza, infatti, ho sempre visto facce stranite. senza parlare di cose complesse, ma di semplici e banali tecniche che ognuno dovrebbe consocere. e non fa piacere.
d'altra parte perfino in mega eventi come PDC o TechEd capita di trovare sessioni davvero "soft". è normale, come già detto al mondo esistono diverse tipologie di sviluppatori ed è giusto dare a tutti l'opportunità di imparare qualcosa.
m.casati ha scritto:
A questo punto faccio una richiesta: organizzare eventi non solo per diffondere una tecnologia ma anche per usarla al meglio (o almeno un po' sopra quel 2% che hai - mi sembra correttamente - stimato)
in genere gli eventi hanno un giusto mix di argomenti semplici e complessi. le volte che mi sono trovato a palare di sicurezza, infatti, ho sempre visto facce stranite. senza parlare di cose complesse, ma di semplici e banali tecniche che ognuno dovrebbe consocere. e non fa piacere.
d'altra parte perfino in mega eventi come PDC o TechEd capita di trovare sessioni davvero "soft". è normale, come già detto al mondo esistono diverse tipologie di sviluppatori ed è giusto dare a tutti l'opportunità di imparare qualcosa.
Daniele Bochicchio scrive:
Re: Entities vs DataSets
nell'ultima cena a Milano ha dato il meglio di sè. alla fine era in preda ai
fumi della carne e voleva prendere un altro caffè a distanza di 2 minuti dal
primo. un mito lo sfizzero
nell'ultima cena a Milano ha dato il meglio di sè. alla fine era in preda ai
fumi della carne e voleva prendere un altro caffè a distanza di 2 minuti dal
primo. un mito lo sfizzero
m.alberti scrive:
Entities vs DataSets
Anch'io ho trovato moloto interessante l'articolo di Dino Esposito, una cosa che mi attira parecchio è l'accenno ai tool di Object/Relational mapping, mi piacerebbe approfondire l'argomento, tu ne sai qualcosa?
Ciao
Maurizio
Anch'io ho trovato moloto interessante l'articolo di Dino Esposito, una cosa che mi attira parecchio è l'accenno ai tool di Object/Relational mapping, mi piacerebbe approfondire l'argomento, tu ne sai qualcosa?
Ciao
Maurizio
»»»» rickyvr scrive:
Re: Entities vs DataSets
Emanuele mi ha preceduto...
NHibernate è un ORM che deriva dal fratello equivalente scritto in ambito Java. Non è l'unico, ma è il più conosciuto. Permette di mappare i due domini, quello applicativo e quello dei dati, tramite una serie di direttive scritte in XML.
Ti consiglio di dare un occhio qui. La versione attuale è la 0.9.0.0.
Qui puoi trovare un articolo con un esempio di utilizzo.
Ciao, Ricky.
Modificato da rickyvr il 11 agosto 2005 11.30 -
Emanuele mi ha preceduto...
NHibernate è un ORM che deriva dal fratello equivalente scritto in ambito Java. Non è l'unico, ma è il più conosciuto. Permette di mappare i due domini, quello applicativo e quello dei dati, tramite una serie di direttive scritte in XML.
Ti consiglio di dare un occhio qui. La versione attuale è la 0.9.0.0.
Qui puoi trovare un articolo con un esempio di utilizzo.
Ciao, Ricky.
Modificato da rickyvr il 11 agosto 2005 11.30 -
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
© 1998-2008 - Ricky.NET - Il blog di Riccardo Golia
Stampa 
Download 
rickyvr