title: asp.net, webapp, reference a js

text:
"AleTV" <
sti...@libbero.it
> wrote in message
news:iug18g$q3c$1...@tdi.cu.mi.it...
> Ma io non voglio disabilitare il caching...
Abbiamo capito cosa non vuoi fare: riesci spiegare cosa e' che vuoi fare?
(Piu' precisamente: qual e' il *requisito*? Altrimenti detto, in gergo
austronautico: quando/come/perche'/cosa?)
> mi basta che venga rispedita la roba quando � pi� aggiornata di quella in
> locale.
La roba fattela mandare via posta ordinaria, vedrai che arriva.
> Uffa, facciamo le astronavi pilotate via web e ste robe di base sul
> caching non si possono fare?
Il web, meglio detto in questo caso *internet programming*, e' un'astronave
di suo! E comunque io sviluppo sistemi informativi, non faccio astronavi:
prova su it.comp.startrek.
> Bho?...
Appunto, roba di base.
-LV
P.S. Non dico di attenerti all'etichetta usenet che' tanto non la conosce
piu' nessuno, pero' cortesemente cambia l'email perche' la trovo offensiva:
per esempio paperino@paperopoli o cose simili sarebbe gia' meno fastidioso.



title: asp.net, webapp, reference a js

author: AleTV

text:
"LudovicoVan" ha scritto nel messaggio
news:iug4tg$2isl$1...@adenine.netfront.net...
> Abbiamo capito cosa non vuoi fare: riesci spiegare cosa e' che vuoi fare?
> (Piu' precisamente: qual e' il *requisito*? Altrimenti detto, in gergo
> austronautico: quando/come/perche'/cosa?)
>
Devo fare un disegnino?
Avere i js lato browser che si aggiornano da soli quando serve (cioè quando
la versione lato server è più aggiornata).
Mi pare sufficientemente chiaro lo scenario...


title: asp.net, webapp, reference a js

author: LudovicoVan

text:
On Saturday, 2 July 2011 12:41:19 UTC+1, AleTV  wrote:
> Avere i js lato browser che si aggiornano da soli quando serve (cioè quando
> la versione lato server è più aggiornata).
> Mi pare sufficientemente chiaro lo scenario...
Si', ero polemico. La soluzione resta la stessa: ammesso che l'applicazione non sia gia' andata on-line, nel qual caso comunque ci sarebbe il problema del browser, devi disabilitare (selettivamente, si spera) il caching lato server. Non c'e' altro modo per assicurarsi che il client abbia sempre e solo la versione aggiornata di una risorsa, a meno che, come gia' detto, non hai accesso ai settings del browser.
(BTW, rispondo da Google Groups perche' il mio news server al momento non va.)
-LV


title: asp.net, webapp, reference a js

text:
"LudovicoVan" ha scritto nel messaggio
news:f207bc56-e8fa-4248...@glegroupsg2000goo.googlegroups.com...
> [...]
>
Scoperto l'arcano... la colpa � del webserver integrato con VS.
Infatti con un web server vero (IIS 6 o 7 che sia) ho visto che il get degli
script ha nello header la clausola If-Modified-Since, quindi il tutto si
risolve da solo.
Pareva strano... :-)


title: asp.net, webapp, reference a js

text:
On Monday, 4 July 2011 20:25:44 UTC+1, AleTV  wrote:
> Scoperto l'arcano... la colpa ï¿½ del webserver integrato con VS.
Semmai pareva strano che tu potessi rispondere qualcosa di sensato, improvvisamente...
Ma sbagliando si impara, per cui buon proseguimento.
-LV


title: asp.net, webapp, reference a js

text:
"LudovicoVan" ha scritto nel messaggio
news:9ace90e3-fb50-4f00...@glegroupsg2000goo.googlegroups.com...
> Semmai pareva strano che tu potessi rispondere qualcosa di sensato,
> improvvisamente...
>
Se hai problemi di comprendonio non � certo colpa mia, sar� la vecchiaia con
arteriosclerosi annessa immagino...
> Ma sbagliando si impara, per cui buon proseguimento.
>
Infatti tu avevi capito fin dall'inizio tutto, furbacchione, solo che non ti
venivano le parole immagino...


title: asp.net, webapp, reference a js

text:
On Wednesday, 6 July 2011 19:26:56 UTC+1, AleTV  wrote:
> Se hai problemi di comprendonio non è certo colpa mia, sarà la vecchiaia con
> arteriosclerosi annessa immagino...
Idiota, quello che nemmeno sa di cosa sta parlando sei tu. Di fatto sei scostumato e indisponente, e sei solo fortunato che il sottoscritto comunque risponde in barba a tutto e tutti: e questo perche', anche se non tu, altri potranno giovarsi delle poche informazioni fornite in questo thread.
> Infatti tu avevi capito fin dall'inizio tutto, furbacchione, solo che non ti
> venivano le parole immagino...
No, io ti ho chiesto di descrivere lo scenario e tu hai insistito a fare una domanda diretta, a cui ho peraltro risposto. Che poi mi e' comunque chiaro dove e come non ti rendi conto e' un altro discorso: i trasferimenti di knowledge aggratis li faccio solo a chi perlomeno conosce le regole di base della civile convivenza.
E mo vatti a lavare la bocca col sapone prima di rifiatare.
-LV


title: asp.net, webapp, reference a js

text:
"LudovicoVan" ha scritto nel messaggio
news:db3ffe20-dc34-47e6...@glegroupsg2000goo.googlegroups.com...
> sei solo fortunato che il sottoscritto comunque risponde in barba a tutto
> e tutti: e questo perche', anche se non tu, altri potranno giovarsi delle
> poche informazioni fornite in
> questo thread.
>
Guarda che se non te ne sei accorto la risposta me la sono data da solo
eh...
> No, io ti ho chiesto di descrivere lo scenario e tu hai insistito a fare
> una domanda diretta, a cui ho peraltro risposto.
>
Scusa, la prossima volta allegher� un UML, contento?
> E mo vatti a lavare la bocca col sapone prima di rifiatare.
>
Mettiti in pensione va... :-D


title: asp.net, webapp, reference a js

text:
"AleTV" <
cogl...@cretino.it
> wrote in message
news:iv2q2g$s4c$1...@tdi.cu.mi.it...
> Guarda che se non te ne sei accorto la risposta me la sono data da solo
> eh...
Si' si', bravo, e per le prossime ti garantisco che sara' lo stesso.
-LV


title: Generics constraint VS subclassing

author: Giulio Petrucci

text:
Forse è davvero talmente facile che non riesco a capirlo ma... che
differenza c'è tra questo:

     public void MyMethod<T>(T item) where T : SomeType { ... }

e questo:

     public void MyMethod(SomeType item) { ... }

?

Grazie,
Giulio

--


title: Generics constraint VS subclassing

author: Mauro Servienti [MVP]

text:
Ciao Giulio,

il primo ti permette di fare un giochetto come questo

class SomeOtherType : SomeType { }
void MyMethod<T>(T item) where T : SomeType
{

}

var obj = new SomeOtherType();
MyMethod<SomeType>( obj );

e internamente sapere che dall'esterno tu vuoi che obj venga
espressamente trattato come SomeType e non come il suo tipo concreto.

.m

--
blog @ //
milestone.topics.it


title: TryCast, CType, DirectCast e congeneri

text:
Ora, il problema è in apparenza banale (visto che nemmeno
esisteva in basic più antichi), nasce dalla necessità di
serializzare strutture, arrays, strutture contenenti arrays
ed arrays di strutture etc, insomma roba VALUE-Type.
Ho fatto già varie ricerche, con esiti che non mi son
piaciuti molto.
Ad es. ho visto usare il marshalling DA/A blocchi di memoria
non gestita, globalHalloc o vattelapesce, IntPtr etcetera.
Ma non vedo la necessità stringente di allocare altra
memoria, copiarci i miei dati, e ricopiare ancora.
Poi ho visto usare le funzioni di serializzazione
BinFormatter.Serialize e BinFormatter.Deserialize, ma solo
con STREAM.
Sto quindi chiedendomi se un qualche genere di cast, dai
tipi aggregati e strutturati che dicevo a byte(), e
viceversa, siano costrutti con un minimo di senso.
Purtroppo se faccio uno static_cast in C++ so cosa
aspettarmi, mentre quando mi muovo in
VB.NET
 non ho idea di
come venga gestita una reference, e in che misura si possa
castare ad altro.
Se vi siete mai trovati a voler gestire con l'immediatezza
del vecchio basic l'I/O su file dei tipo
strutturati/aggregati anche con .NET, come avete risolto ?
Pensate che ci sia qualche modo di castare semplicemente il
tipo di dati e imbrogliare ?
Preciso una cosa importante : faccio di tutto per mantenere
il layout di queste strutture compatto e non sparso (array
di dimensioni fisse, stringhe di lunghezza fissa e attributi
<serializable()>, poi non so se alla fine le strutture siano
impaccate o sparse ugualmente ... in questo caso mi rendo
conto che, SE fungesse, un CAST sarebbe devastante.
Quindi ne sorge una sottodomanda : se ci sia un modo per
tenere compatta, monolitica, la rappresentazione di memoria
di questi tipi utente (ribadisco, senza pezzi dinamici
dentro, se no pare dura anche in teoria).
ciao
grazie in anticipo
Soviet


title: TryCast, CType, DirectCast e congeneri

text:
Ciao Soviet_Mario,
You wrote on 07/01/2011 :
> Pensate che ci sia qualche modo di castare semplicemente il tipo di dati e
> imbrogliare ?
no
> Preciso una cosa importante : faccio di tutto per mantenere il layout di
> queste strutture compatto e non sparso (array di dimensioni fisse, stringhe
> di lunghezza fissa e attributi <serializable()>, poi non so se alla fine le
> strutture siano impaccate o sparse ugualmente ... in questo caso mi rendo
> conto che, SE fungesse, un CAST sarebbe devastante.
> Quindi ne sorge una sottodomanda : se ci sia un modo per tenere compatta,
> monolitica, la rappresentazione di memoria di questi tipi utente (ribadisco,
> senza pezzi dinamici dentro, se no pare dura anche in teoria).
precisando in primis che non ho capito quale sia il problema, in .net
il processo di serializzazione è sempre delegato ai Formatter, da un
gravo verso unp stream attraverso un formatter, lo stream ovviamente
non è una risorsa astratta quindi sarà "montato" su qualcosa, come la
memoria nel caso più semplice e quindi un byte[]
> ciao
> grazie in anticipo
> Soviet
--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @
http://milestone.topics.it
whynot [ at ] topics [ dot ] it


title: TryCast, CType, DirectCast e congeneri

text:
Il 08/01/2011 06:42, Mauro Servienti [MVP] ha scritto:
> Ciao Soviet_Mario,
>
> You wrote on 07/01/2011 :
>> Pensate che ci sia qualche modo di castare semplicemente il tipo di
>> dati e imbrogliare ?
>
> no
eh, lo temevo
>
>> Preciso una cosa importante : faccio di tutto per mantenere il layout
>> di queste strutture compatto e non sparso (array di dimensioni fisse,
>> stringhe di lunghezza fissa e attributi <serializable()>, poi non so
>> se alla fine le strutture siano impaccate o sparse ugualmente ... in
>> questo caso mi rendo conto che, SE fungesse, un CAST sarebbe devastante.
>> Quindi ne sorge una sottodomanda : se ci sia un modo per tenere
>> compatta, monolitica, la rappresentazione di memoria di questi tipi
>> utente (ribadisco, senza pezzi dinamici dentro, se no pare dura anche
>> in teoria).
>
> precisando in primis che non ho capito quale sia il problema,
serializzare in modo DIRETTO, ossia scrivere su disco un
layout binario praticamente fotocopia di quello in memoria.
Con l'antico VB, tipi utente (Type) e GET / PUT, usando tipi
utente giusti (array statici e stringhe a lunghezza fissa)
era grossomodo possibile, salvo il padding, che cmq rimaneva
trasparente.
Invece ho letto sull'help M$ che serialize/unserialize, a
fronte di vantaggio indubbi (e che non mi servono, tipo le
deep copy di un intero grafo, a me serve solo shallow copy),
hanno un overspace inaccettabile per altri miei fini, cioè
scrivono un sacco di informazioni (tipo nome dell'assembly,
della classe, descrittori e metadati vari), che saranno
utili a lui per deserializzare, ma mi tornano nocivi.
Però non so usare i formatter. Cosa dovrei cercare ? E ci
sarebbe modo usando un formatter opportuno, di far scrivere
solo quel che dico io ? Cioè omettere tutti i vari metadati
ed info accessorie ? Senza che poi ovviamente floppi la
deserializzazione da disco a memoria
> .net il
> processo di serializzazione è sempre delegato ai Formatter, da un gravo
> verso unp stream attraverso un formatter, lo stream ovviamente non è una
> risorsa astratta quindi sarà "montato" su qualcosa, come la memoria nel
> caso più semplice e quindi un byte[]
ciao e grazie
Soviet



title: TryCast, CType, DirectCast e congeneri

author: Raffaele Rialdi [MVP]

text:
Soviet_Mario wrote:
> serializzare in modo DIRETTO, ossia scrivere su disco un layout binario
> praticamente fotocopia di quello in memoria.
> Con l'antico VB, tipi utente (Type) e GET / PUT, usando tipi utente giusti
> (array statici e stringhe a lunghezza fissa) era grossomodo possibile, salvo
> il padding, che cmq rimaneva trasparente.
Per definizione il layout di memoria in .net non può e non deve essere
noto. Diversamente ti perderesti la riusabilità in altre
piattaforme/OS/etc.
Pensa solo al problema di serializzare/deserializzare da 32 a 64 bit o
al problema di big/little endian che hai in C++ proprio per aver
fotocopiato la struttuta di memoria su disco.
E poi anche in C++ ci sono dozzine di casi in cui non è possibile e la
nascita di IDL (sia in COM che Corba) è proprio dovuta a questi grossi
limiti.
Infine la serializzazione non deve mai essere un processo automatizzato
ma deve essere pilotata dal developer che indica dove clonare il resto
del grafo o dove fermarsi (deep/shallow copy).
>
> Invece ho letto sull'help M$
Sorry ma sono allergico alla dicitura M$, io non scrivo Linu$ Torvalds
e non credo che muoia di fame.
> che serialize/unserialize, a fronte di vantaggio
> indubbi (e che non mi servono, tipo le deep copy di un intero grafo, a me
> serve solo shallow copy), hanno un overspace inaccettabile per altri miei
> fini, cioè scrivono un sacco di informazioni (tipo nome dell'assembly, della
> classe, descrittori e metadati vari), che saranno utili a lui per
> deserializzare, ma mi tornano nocivi.
Se devi fare solo una shallow copy è decisamente semplice. Ti basta
marcare [Serialize] la classe/struct e poi mettere [NonSerialized] sui
field che non vuoi serializzare.
> Però non so usare i formatter. Cosa dovrei cercare ? E ci sarebbe modo usando
> un formatter opportuno, di far scrivere solo quel che dico io ? Cioè omettere
> tutti i vari metadati ed info accessorie ? Senza che poi ovviamente floppi la
> deserializzazione da disco a memoria
Questo è il binary formatte (+esempio):
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatters.binary.binaryformatter.aspx
ma ce ne sono altri come XmlSerializer, DataContractSerializer, ...
Ciao
--
Raffaele Rialdi
http://www.iamraf.net
Weblog:
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET -
http://www.ugidotnet.org/


title: TryCast, CType, DirectCast e congeneri

text:
Il 08/01/2011 13:14, Raffaele Rialdi [MVP] ha scritto:
> Soviet_Mario wrote:
>> serializzare in modo DIRETTO, ossia scrivere su disco un layout
>> binario praticamente fotocopia di quello in memoria.
>> Con l'antico VB, tipi utente (Type) e GET / PUT, usando tipi utente
>> giusti (array statici e stringhe a lunghezza fissa) era grossomodo
>> possibile, salvo il padding, che cmq rimaneva trasparente.
>
> Per definizione il layout di memoria in .net non può e non deve essere
> noto. Diversamente ti perderesti la riusabilità in altre
> piattaforme/OS/etc.
beh, non so se la mera conoscenza, senza interventi veri e
propri, comporti perdite.
Tuttosommato i dati "atomici", ossia i mattoni elementari,
intendo copiarli senza alcuna intromissione o assunzione
particolare, e supporrei, magari errando, che ogni peculiare
endian-ness, come pure bit ordering (msb, lsb), venga
assorbita da questo rispetto dei tipi fondamentali.
Padding a parte (per il quale cercavo strategie abbastanza
pulite ossia previste di compattazione), credo che un
aggregato comunque intricato, costruito a partire da tipi
atomici trattati così come sono, venga smontato e rimontato
correttamente.
In effetti si, la portabilità è probabilmente la
caratteristica che più mi alletta di NET
> Pensa solo al problema di serializzare/deserializzare da 32 a 64 bit
beh, credo che vorrei appunto poter indicare che in quel
dato campo io pretendo un intero a 16 bit e in quell'altro a
32. Poi lascio al compilatore decidere come disporre i byte,
e la endianness. Ma l'ampiezza di default della word
macchina non dovrebbe interferire con la profondità di byte
dei miei dati strutturati. Sta a me decidere quanto spazio
merita quella certa informazione, non dovrei consentire che
siano terzi a deciderla.
Volere questo è non portabile ? Mi baserei sull'unico
assunto che un byte è otto bit su qualsiasi macchina, per
dimensionare gli integral types. Solo su questo.
E, per smontare / rimontare interi multibyte, uso routines
speculari, che qualsiasi impatto di ribaltamento di ordine,
dovrebbero invertirlo quando chiamate in coppia
> o
> al problema di big/little endian che hai in C++ proprio per aver
> fotocopiato la struttuta di memoria su disco.
beh, è un problema nella misura in cui scrivi codice che
assume un certo orientamento fisso e non lo prende come
parametro. Ma non ho esigenza di controllare o sapere sino a
questo dettaglio, nello specifico
> E poi anche in C++ ci sono dozzine di casi in cui non è possibile e la
> nascita di IDL (sia in COM che Corba) è proprio dovuta a questi grossi
> limiti.
>
> Infine la serializzazione non deve mai essere un processo automatizzato
> ma deve essere pilotata dal developer che indica dove clonare il resto
> del grafo o dove fermarsi (deep/shallow copy).
>
>
>>
>> Invece ho letto sull'help M$
>
> Sorry ma sono allergico alla dicitura M$, io non scrivo Linu$ Torvalds e
> non credo che muoia di fame.
:-) Uh, no, non volevo certo offendere nessuno o la
sensibilità di nessuno. Suppongo di averlo fatto, ma
inavvertitamente. Circa Torvalds, ammetto di non avere mai
utilizzato nessun sistema Linux o Unix (nemmeno altri
eccetto Win), ergo come lo si chiami non è che mi tolga il
sonno (sono un win user dal 1989). M$ era, imho ovviamente,
solo molto breve.
Ma non userò più tale acronimo se urta chicchessia.
>
>> che serialize/unserialize, a fronte di vantaggio indubbi (e che non mi
>> servono, tipo le deep copy di un intero grafo, a me serve solo shallow
>> copy), hanno un overspace inaccettabile per altri miei fini, cioè
>> scrivono un sacco di informazioni (tipo nome dell'assembly, della
>> classe, descrittori e metadati vari), che saranno utili a lui per
>> deserializzare, ma mi tornano nocivi.
>
> Se devi fare solo una shallow copy è decisamente semplice. Ti basta
> marcare [Serialize] la classe/struct e poi mettere [NonSerialized] sui
> field che non vuoi serializzare.
Sin qui ok ... ma come impedire che vengano scritte tutte le
informazioni accessorie che citavo, tipo nome della classe,
dell'assembly, e altri metadati che non so ancora come
controllare esplicitamente ? Non ci sta qualche maniera di
scrivere dati nudi ?
Aggiungo che ho bisogno di potere eseguire delle SEEK a
posizioni ben precise, relative, entro il file (tipo
immagina array di puntatori a record, pezzi doppiamente
linkati tra loro etc etc). Quindi devo sapere per bene a che
byte sta salvando, quanti ce ne mette, e cose del genere.
Non sono ancora riuscito a capire se durante la
serializzazione built in possa tenere traccia di questo, e
poi magari tornare a record precedenti e fare update.
Aggiungo anche che non si tratta di un file a lunghezza
record costante, e neppure omogeneo in quanto a struttura in
ogni punto. Diciamo che la struttura interna è un tantino
incasinata, perché riproduce in certa misura strutture date
di memoria come array di stringhe arbitrarie, liste linkate,
dizionario etc.
>
>
>> Però non so usare i formatter. Cosa dovrei cercare ? E ci sarebbe modo
>> usando un formatter opportuno, di far scrivere solo quel che dico io ?
>> Cioè omettere tutti i vari metadati ed info accessorie ? Senza che poi
>> ovviamente floppi la deserializzazione da disco a memoria
>
> Questo è il binary formatte (+esempio):
>
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatters.binary.binaryformatter.aspx
>
>
Ci vo' a dare un'occhiata, grazie. Quand'anche non mi
servissero per il caso specifico, in effetti sto imparando
cose varie che magari mi tornano utili in altro momento.
ciao e grazie
Soviet



title: TryCast, CType, DirectCast e congeneri

text:
On Jan 8, 1:59 pm, Soviet_Mario <Soviet.Ma...@CCCP.MIR> wrote:
> Il 08/01/2011 13:14, Raffaele Rialdi [MVP] ha scritto:
>
> > Soviet_Mario wrote:
> >> serializzare in modo DIRETTO, ossia scrivere su disco un layout
> >> binario praticamente fotocopia di quello in memoria.
> >> Con l'antico VB, tipi utente (Type) e GET / PUT, usando tipi utente
> >> giusti (array statici e stringhe a lunghezza fissa) era grossomodo
> >> possibile, salvo il padding, che cmq rimaneva trasparente.
>
> > Per definizione il layout di memoria in .net non può e non deve essere
> > noto. Diversamente ti perderesti la riusabilità in altre
> > piattaforme/OS/etc.
>
> beh, non so se la mera conoscenza, senza interventi veri e
> propri, comporti perdite.
>
> Tuttosommato i dati "atomici", ossia i mattoni elementari,
> intendo copiarli senza alcuna intromissione o assunzione
> particolare, e supporrei, magari errando, che ogni peculiare
> endian-ness, come pure bit ordering (msb, lsb), venga
> assorbita da questo rispetto dei tipi fondamentali.
A parte che, tecnicamente, cio' che dici non e' corretto (questioni di
endianness e simili ce l'hai anche e proprio a partire dai tipi
primitivi, e le tue eventuali strutture dati si pongono sempre ad un
livello piu' alto).
Comunque, il punto fondamentale che a mio modesto avviso rischia un
po' di sfuggirti e' che .Net uguale mondo managed, cioe' comporta un
approccio alla programmazione piu' ad alto livello. Paragoni e ancora
di piu' *paradigmi* estrapolati da quelli del C/C++ per esempio, sono
del tutto fuori luogo...
Per usare al meglio .Net occorre conoscere bene il framework, la sua
specifica ed i suoi vincoli e limiti. Quindi anch'io ti suggerirei di
guardare meglio la documentazione sulla serializzazione/
deserializzazione: primo perche' quello e' l'approccio "corretto"
in .Net di pensare e poi risolvere certi problemi, e poi, non del
tutto secondario, perche' molti dei tuoi dubbi e delle tue idee di
soluzione "piu' a basso livello" in realta' sono ingiustificati,
tecnicamente scorretti, e appunto derivano piu' che altro da una tua
mancanza di adeguata conoscenza del framework e dei suoi idiomi.
My 2c anyway, e ti invito amichevolmente a prenderla come una critica
positiva!
-LV


title: TryCast, CType, DirectCast e congeneri

text:
Soviet_Mario wrote:
> beh, non so se la mera conoscenza, senza interventi veri e propri, comporti
> perdite.
> Tuttosommato i dati "atomici", ossia i mattoni elementari, intendo copiarli
> senza alcuna intromissione o assunzione particolare, e supporrei, magari
> errando, che ogni peculiare endian-ness, come pure bit ordering (msb, lsb),
> venga assorbita da questo rispetto dei tipi fondamentali.
> Padding a parte (per il quale cercavo strategie abbastanza pulite ossia
> previste di compattazione), credo che un aggregato comunque intricato,
> costruito a partire da tipi atomici trattati così come sono, venga smontato e
> rimontato correttamente.
Come scrive anche Ludovico, il problema è proprio sui tipi fondamentali
e spesso si è rivelato un problema anche tra librerie C.
> beh, credo che vorrei appunto poter indicare che in quel dato campo io
> pretendo un intero a 16 bit e in quell'altro a 32. Poi lascio al compilatore
> decidere come disporre i byte, e la endianness. Ma l'ampiezza di default
> della word macchina non dovrebbe interferire con la profondità di byte dei
> miei dati strutturati. Sta a me decidere quanto spazio merita quella certa
> informazione, non dovrei consentire che siano terzi a deciderla.
> Volere questo è non portabile ? Mi baserei sull'unico assunto che un byte è
> otto bit su qualsiasi macchina, per dimensionare gli integral types. Solo su
> questo.
[...]
per fare une sempio in C++ un int non è sempre 32 bit.
Inoltre la serializzazione risolve altri tipi di problemi come il
versioning perché un blob di per se non è esaustivo del tipo
originario.
Lasciami dire però che sono tutti discorsi inutili perché già
ampiamente trattati negli anni 80. SOAP è nato per risolvere la
serializzazione nel distribuito e potremmo star qui a tirare fuori
molti altri esempi.
L'unica conclusione ormai assodata è che la copia della memoria è del
tutto insufficiente e poco utile.
> Sin qui ok ... ma come impedire che vengano scritte tutte le informazioni
> accessorie che citavo, tipo nome della classe, dell'assembly, e altri
> metadati che non so ancora come controllare esplicitamente ? Non ci sta
> qualche maniera di scrivere dati nudi ?
Puoi anche prendere controllo della serializzazione implementando
IXmlSerializable (ovviamente scrivendo xml) ma non vedo a che
servirebbe avere un blob 'nudo'.
Non puoi "pensare alla C" quando usi linguaggi managed. È proprio un
approccio differente. Sarebbe come fare un cast ad un (miotipo *) su un
blob. Tipico del C (non di C++) e non fattibile con i linguaggi
puramente managed.
> Aggiungo che ho bisogno di potere eseguire delle SEEK a posizioni ben
> precise, relative, entro il file (tipo immagina array di puntatori a record,
> pezzi doppiamente linkati tra loro etc etc). Quindi devo sapere per bene a
> che byte sta salvando, quanti ce ne mette, e cose del genere.
> Non sono ancora riuscito a capire se durante la serializzazione built in
> possa tenere traccia di questo, e poi magari tornare a record precedenti e
> fare update.
> Aggiungo anche che non si tratta di un file a lunghezza record costante, e
> neppure omogeneo in quanto a struttura in ogni punto. Diciamo che la
> struttura interna è un tantino incasinata, perché riproduce in certa misura
> strutture date di memoria come array di stringhe arbitrarie, liste linkate,
> dizionario etc.
Ecco l'esempio della scrittura/lettura di strutture a record è
l'esempio che faccio nei miei corsi di .net su come *non* usare il
framework.
Provare a fare cose di questo tipo con C# è quanto di più inefficiente
e deleterio.
Devi pensare la tua soluzione in modo diverso.
> Ci vo' a dare un'occhiata, grazie. Quand'anche non mi servissero per il caso
> specifico, in effetti sto imparando cose varie che magari mi tornano utili in
> altro momento.
Prego, ciao



title: TryCast, CType, DirectCast e congeneri

text:
Il 08/01/2011 19:58, LudovicoVan ha scritto:
> On Jan 8, 1:59 pm, Soviet_Mario<Soviet.Ma...@CCCP.MIR>  wrote:
>> Il 08/01/2011 13:14, Raffaele Rialdi [MVP] ha scritto:
>>
>>> Soviet_Mario wrote:
>>>> serializzare in modo DIRETTO, ossia scrivere su disco un layout
>>>> binario praticamente fotocopia di quello in memoria.
>>>> Con l'antico VB, tipi utente (Type) e GET / PUT, usando tipi utente
>>>> giusti (array statici e stringhe a lunghezza fissa) era grossomodo
>>>> possibile, salvo il padding, che cmq rimaneva trasparente.
>>
>>> Per definizione il layout di memoria in .net non può e non deve essere
>>> noto. Diversamente ti perderesti la riusabilità in altre
>>> piattaforme/OS/etc.
>>
>> beh, non so se la mera conoscenza, senza interventi veri e
>> propri, comporti perdite.
>>
>> Tuttosommato i dati "atomici", ossia i mattoni elementari,
>> intendo copiarli senza alcuna intromissione o assunzione
>> particolare, e supporrei, magari errando, che ogni peculiare
>> endian-ness, come pure bit ordering (msb, lsb), venga
>> assorbita da questo rispetto dei tipi fondamentali.
>
> A parte che, tecnicamente, cio' che dici non e' corretto (questioni di
> endianness e simili ce l'hai anche e proprio a partire dai tipi
> primitivi,
sono stato frainteso : intendevo dire che a quel livello non
volevo INTERFERIRE col sistema, ma salvarli/caricarli "as
is", con tutte le specifiche interne che hanno.
L'unico controllo che prendevo era usare interi come
uint16, uint32, uint64 e così via, non il "plain integer"
(proprio per evitare assunzioni scivolose, come mi fa notare
anche Rialdi nell'altro post, scivolosità di cui cmq sono al
corrente, a basso livello).
> e le tue eventuali strutture dati si pongono sempre ad un
> livello piu' alto).
quel che volevo dire era che se leggo/scrivo i tipi atomici
senza interferenze o assunzioni particolari, il linguaggio
mi garantisce di scriverli e leggerli correttamente
dappertutto. Se mi espone un uint32 non mi garantisce forse
che avrà 32 bit su qualsiasi macchina, a prescindere dal
mettere i byte consecutivi o come gli pare ?
Bene, rispettato questo, se salvo una struttura smontandola
pezzo a pezzo, quando la rileggo e la rimonto pezzo a pezzo,
conto di riottenerla in uno stato identico.
Poi magari non è vero ... nel caso, ditemelo. Ma sarebbe
allarmante al di là di qualsiasi filosofia ispiratrice.
Oltretutto così facendo non sto facendo una fotocopia della
RAM su disco, checché se ne dica, perché non impongo nessun
vincolo di alignment, di padding etc, ma sia il memory
manager sia il file system collocano questi "atomi" come
meglio credono. In fondo è una serializzazione manuale.
Ma è tediosa e error prone, mi sarebbe piaciuto poter
istruire il serializzazione di serie a farle lui ste cose
... magari imparerò, come giustamente mi dite entrambi, so
poco di NET, anche se pian piano qualcosa imparo
>
> Comunque, il punto fondamentale che a mio modesto avviso rischia un
> po' di sfuggirti e' che .Net uguale mondo managed, cioe' comporta un
> approccio alla programmazione piu' ad alto livello. Paragoni e ancora
> di piu' *paradigmi* estrapolati da quelli del C/C++ per esempio, sono
> del tutto fuori luogo...
beh, in questo caso sto solo traducendo codice VB6, manco
poi tanto a basso livello. Hanno deciso di stroncare il
supporto dei tipi utente verso il file system. Non ho voluto
farlo io, ma è così, e ci devo mettere una pezza.
>
> Per usare al meglio .Net occorre conoscere bene il framework, la sua
> specifica ed i suoi vincoli e limiti. Quindi anch'io ti suggerirei di
> guardare meglio la documentazione sulla serializzazione/
> deserializzazione: primo perche' quello e' l'approccio "corretto"
> in .Net di pensare e poi risolvere certi problemi, e poi, non del
> tutto secondario, perche' molti dei tuoi dubbi e delle tue idee di
> soluzione "piu' a basso livello" in realta' sono ingiustificati,
beh diciamo che il formato del file è un vincolo a cui devo
aderire, corretto o scorretto tecnicamente che sia.
> tecnicamente scorretti, e appunto derivano piu' che altro da una tua
> mancanza di adeguata conoscenza del framework e dei suoi idiomi.
questo è in sé stesso vero, ma quel formato precede
l'esistenza del framework, che ci posso fare ?
>
> My 2c anyway, e ti invito amichevolmente a prenderla come una critica
> positiva!
ci mancherebbe ! Mai trovato un NG con disponibilità alle
spiegazioni così valida.
Anzi, ringrazio qui anche Rialdi che mi ha più volte dato
molte dritte preziose nel pur breve tempo che ho frequentato
questo posto.
ciao
Soviet
>
> -LV


title: TryCast, CType, DirectCast e congeneri

text:
Il 08/01/2011 22:31, Raffaele Rialdi [MVP] ha scritto:
> Soviet_Mario wrote:
>> beh, non so se la mera conoscenza, senza interventi veri e propri,
>> comporti perdite.
>> Tuttosommato i dati "atomici", ossia i mattoni elementari, intendo
>> copiarli senza alcuna intromissione o assunzione particolare, e
>> supporrei, magari errando, che ogni peculiare endian-ness, come pure
>> bit ordering (msb, lsb), venga assorbita da questo rispetto dei tipi
>> fondamentali.
>> Padding a parte (per il quale cercavo strategie abbastanza pulite
>> ossia previste di compattazione), credo che un aggregato comunque
>> intricato, costruito a partire da tipi atomici trattati così come
>> sono, venga smontato e rimontato correttamente.
>
> Come scrive anche Ludovico, il problema è proprio sui tipi fondamentali
> e spesso si è rivelato un problema anche tra librerie C.
>
beh, non mi metto a fare bit-shift sui dati cmq. Li leggo e
scrivo su disco, il resto facciano loro :)
>
>> beh, credo che vorrei appunto poter indicare che in quel dato campo io
>> pretendo un intero a 16 bit e in quell'altro a 32. Poi lascio al
>> compilatore decidere come disporre i byte, e la endianness. Ma
>> l'ampiezza di default della word macchina non dovrebbe interferire con
>> la profondità di byte dei miei dati strutturati. Sta a me decidere
>> quanto spazio merita quella certa informazione, non dovrei consentire
>> che siano terzi a deciderla.
>> Volere questo è non portabile ? Mi baserei sull'unico assunto che un
>> byte è otto bit su qualsiasi macchina, per dimensionare gli integral
>> types. Solo su questo.
> [...]
>
> per fare une sempio in C++ un int non è sempre 32 bit.
infatti molto di rado uso i tipi "plain int" e simili.
quasi sempre, almeno laddove è critico, come qui, uso quelli
strettamente tipizzati, uint16, uint32, uint64 (mi servono
gli unsigned quasi sempre in quel file)
> Inoltre la serializzazione risolve altri tipi di problemi come il
> versioning perché un blob di per se non è esaustivo del tipo originario.
ah. ... Cmq, siccome non so cosa sia il versioning, ma quel
benedetto formato di file probabilmente è più antico dello
stesso, o comunque non è rilevante, spererei che possa non
interessarmi il versioning.
>
> Lasciami dire però che sono tutti discorsi inutili perché già ampiamente
> trattati negli anni 80. SOAP è nato per risolvere la serializzazione nel
> distribuito e potremmo star qui a tirare fuori molti altri esempi.
> L'unica conclusione ormai assodata è che la copia della memoria è del
> tutto insufficiente e poco utile.
Premesso che non mi serve necessariamente una fotocopia 1:1,
è pur vero che mi servono solo i dati dichiarati, e se non
nello stesso ordine fisico, almeno nello stesso ordine
logico. Cioè devo poterli cercare sapendo a che offset li
trovo, se no il formato file non funge.
Quel file è una sorta di matriosca, in cui alcune zone sono
scatole di scatole, e a vari livelli si sovrappongono
criptatura e compressione dei blocchi. Alcuni si
referenziano tra loro.
Ora non dubito che con le serialize/deserialize di serie si
riuscirebbe a supportare questo, ma dovrei riscrivere
completamente tutto.
Ergo volentieri mi basterebbe riuscire a salvare le
strutture tal quali, almeno il resto del codice sta in piedi
>
>> Sin qui ok ... ma come impedire che vengano scritte tutte le
>> informazioni accessorie che citavo, tipo nome della classe,
>> dell'assembly, e altri metadati che non so ancora come controllare
>> esplicitamente ? Non ci sta qualche maniera di scrivere dati nudi ?
>
> Puoi anche prendere controllo della serializzazione implementando
> IXmlSerializable (ovviamente scrivendo xml) ma non vedo a che servirebbe
> avere un blob 'nudo'.
Proverò a documentarmi su quest'interfaccia che dici.
> Non puoi "pensare alla C" quando usi linguaggi managed. È proprio un
> approccio differente.
Si, okay. Ma qui mi riferisco solo a un formato di file. Non
voglio interferire con la memoria. E' anche per questo che
storco un po' il naso a voler fare allocazioni nello heap
non managed, e a imporre marshalling strani. In memoria
lascerei volentieri tutto alla gestione nativa.
> Sarebbe come fare un cast ad un (miotipo *) su un
> blob. Tipico del C (non di C++) e non fattibile con i linguaggi
> puramente managed.
poi mi cercerò anche questa parola, BLOB, che non conosco
>
>> Aggiungo che ho bisogno di potere eseguire delle SEEK a posizioni ben
>> precise, relative, entro il file (tipo immagina array di puntatori a
>> record, pezzi doppiamente linkati tra loro etc etc). Quindi devo
>> sapere per bene a che byte sta salvando, quanti ce ne mette, e cose
>> del genere.
>> Non sono ancora riuscito a capire se durante la serializzazione built
>> in possa tenere traccia di questo, e poi magari tornare a record
>> precedenti e fare update.
>> Aggiungo anche che non si tratta di un file a lunghezza record
>> costante, e neppure omogeneo in quanto a struttura in ogni punto.
>> Diciamo che la struttura interna è un tantino incasinata, perché
>> riproduce in certa misura strutture date di memoria come array di
>> stringhe arbitrarie, liste linkate, dizionario etc.
>
> Ecco l'esempio della scrittura/lettura di strutture a record è l'esempio
> che faccio nei miei corsi di .net su come *non* usare il framework.
:(
L'impatto di cambiare formato fisico del file di appoggio,
che è proprio il cuore di tutto, sarebbe troppo oneroso.
Oltretutto non so se saprei mantenere "sicuro" il sistema.
Ora una delle robustezze è anche questa sua struttura
incasinata, che lo rendono abbastanza oscuro dall'esterno
> Provare a fare cose di questo tipo con C# è quanto di più inefficiente e
> deleterio.
>
> Devi pensare la tua soluzione in modo diverso.
:-\
Non è molto il codice implicato che mi serve, in realtà.
Solo la parte che interagisce col file fisico.
Per adesso sto mettendo delle pezze temporanee, ed ogni
struttura e classe, dalla più infima, implementa suoi metodi
omonimi CopyTo e CopyFrom, da/ad array di byte, e qualche
routine su array per assemblare e disassemblare, o delega a
quelle sottostanti nelle classi derivate.
Ma è stato molto tedioso, sono pomeriggi che faccio questa
porcheria di serializzazione a mano.
Spero di trovare di meglio in quell'interfaccia che mi hai
consigliato
ciao e grazie
Soviet


title: TryCast, CType, DirectCast e congeneri

text:
Soviet_Mario wrote:
> beh, non mi metto a fare bit-shift sui dati cmq. Li leggo e scrivo su disco,
> il resto facciano loro :)
capisco, ma il problema è anche sui tipi di base.
> ah. ... Cmq, siccome non so cosa sia il versioning, ma quel benedetto formato
> di file probabilmente è più antico dello stesso, o comunque non è rilevante,
> spererei che possa non interessarmi il versioning.
il versioning si riferisce alla versione della classe che stai
serializzando.
Leggiti questi articoli. Qui c'è il numero 3 da cui poi trovi i link
per la parte 1 e 2.
http://msdn.microsoft.com/en-us/magazine/cc188950.aspx
Sono un eccellente spiegazione (non per niente scrive Richter) della
serializzazione nel mondo managed.
> Premesso che non mi serve necessariamente una fotocopia 1:1, è pur vero che
> mi servono solo i dati dichiarati, e se non nello stesso ordine fisico,
> almeno nello stesso ordine logico. Cioè devo poterli cercare sapendo a che
> offset li trovo, se no il formato file non funge.
> Quel file è una sorta di matriosca, in cui alcune zone sono scatole di
> scatole, e a vari livelli si sovrappongono criptatura e compressione dei
> blocchi. Alcuni si referenziano tra loro.
> Ora non dubito che con le serialize/deserialize di serie si riuscirebbe a
> supportare questo, ma dovrei riscrivere completamente tutto.
> Ergo volentieri mi basterebbe riuscire a salvare le strutture tal quali,
> almeno il resto del codice sta in piedi
Per abilitare la serializzazione il lavoro è poco. Poi se vuoi farci
cose strane può anche diventare un lavoro lungo ma di base è banale.
Leggiti gli articoli di cui sopra e vedrai con i tuoi occhi
> Si, okay. Ma qui mi riferisco solo a un formato di file. Non voglio
> interferire con la memoria. E' anche per questo che storco un po' il naso a
> voler fare allocazioni nello heap non managed, e a imporre marshalling
> strani. In memoria lascerei volentieri tutto alla gestione nativa.
Oggi serializzi poi domani vai su un altro pc (hw differente) e vuoi
deserializzare. Che succede?
Il CLR fa si che questo sia totalmente trasparente e funzioni tutto
anche se la struttura di quella classe in memoria sia rappresentata in
modo differente per sfruttare la piattaforma hardware o sfruttare le
performance.
Qui non è questione di "mi basta fare ..." ma è un approccio che il
framework deve risolvere in modo definitivo senza "se" o "ma".
> poi mi cercerò anche questa parola, BLOB, che non conosco
Binary Large OBject
> :(
> L'impatto di cambiare formato fisico del file di appoggio, che è proprio il
> cuore di tutto, sarebbe troppo oneroso.
> Oltretutto non so se saprei mantenere "sicuro" il sistema. Ora una delle
> robustezze è anche questa sua struttura incasinata, che lo rendono abbastanza
> oscuro dall'esterno
Quando pensi in modo managed devi cercare di rimanere più ad alto
livello, slegato dal formato fisico.
Inoltre se lo fai per un motivo di security, sappi che "security
through obscurity" è una soluzione fallimentare. Cioè non si protegge
mai nulla solo perché nascondi qualcosa del sistema. I migliori
algoritmi di criptazione sono pubblici.
> :-\
> Non è molto il codice implicato che mi serve, in realtà. Solo la parte che
> interagisce col file fisico.
> Per adesso sto mettendo delle pezze temporanee, ed ogni struttura e classe,
> dalla più infima, implementa suoi metodi omonimi CopyTo e CopyFrom, da/ad
> array di byte, e qualche routine su array per assemblare e disassemblare, o
> delega a quelle sottostanti nelle classi derivate.
Non è un approccio vincente nel mondo managed.
>
> Ma è stato molto tedioso, sono pomeriggi che faccio questa porcheria di
> serializzazione a mano.
> Spero di trovare di meglio in quell'interfaccia che mi hai consigliato
> ciao e grazie
Prego e buono studio allora ...



title: [VS] Evento compilazione

author: ferradini

text:
Volevo sapere se esiste un qualcosa che mi possa segnalare l'avvenuta
compilazione di un sorgente in c# ad esempio scatenare un evento, oppure
aggiornare un contatore, aggiungere un record ad un database. Grazie
Ferradini


title: [VS] Evento compilazione

text:

Nei post build event hai modo di invocare quello che preferisci.
Vai nelle proprietà del progetto, sulla sinistra scegli Build Events.
Lì trovi gli eventi pre e post build.
--
Raffaele Rialdi
http://www.iamraf.net
Weblog:
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET -
http://www.ugidotnet.org/


title: [VS] Evento compilazione

text:
> Nei post build event hai modo di invocare quello che preferisci.
> Vai nelle proprietà del progetto, sulla sinistra scegli Build Events.
> Lì trovi gli eventi pre e post build.
ok, quindi mi sembra di capire che nella riga evento post-compilazione
devo scrivere un file tipo .bat oppure un'applicazione da eseguire.
Giusto?


title: [VS] Evento compilazione

text:
ferradini wrote:
> ok, quindi mi sembra di capire che nella riga evento post-compilazione devo
> scrivere un file tipo .bat oppure un'applicazione da eseguire.
> Giusto?
Esatto, un bat, un cmd, o una riga 'secca' (tipo xcopy /e /s ...) in
cui puoi usare le macro che la dialog stessa ti permette di definire
come ad esempio: $(SolutionDir)



title: [VS] Evento compilazione

text: Grazie. Ferradini


title: metodo corretto con EF

author: Sander

text:
una domanda che mi sorge osservando un comportamento strano.
In un metodo come questo, che mi restituisce un 'contatto' da un DB
fornendo l'id, è corretto utilizzare il primo esempio, che utilizza un
oggetto di tipo perEntities definito una sola volta in una classe
visibile a tutta l'applicazione (classe GV) , oppure è necessario
reistanziare un oggetto perEntities ad ogni chiamata del metodo, secondo
esempio ?
Grazie molte.
Sander
  public static contatti GetContattobyID(int id)
         {
                         var query = from c in GV.EntityPer.contatti
                             where
c.id
 == id
                             select c;
                 if (query.Count() > 0) return query.First();
                 else return null;
         }
      public static contatti GetContattobyID(int id)
         {              PerEntities Ent = new PerEntities();
                         var query = from c in Ent.contatti
                             where
c.id
 == id
                             select c;
                 if (query.Count() > 0) return query.First();
                 else return null;
         }


title: metodo corretto con EF

author: Andrea Saltarello

text:
Il 06/02/11 11.42, Sander ha scritto:
> In un metodo come questo, che mi restituisce un 'contatto' da un DB
> fornendo l'id, è corretto utilizzare il primo esempio, che utilizza un
> oggetto di tipo perEntities definito una sola volta in una classe
> visibile a tutta l'applicazione (classe GV) , oppure è necessario
> reistanziare un oggetto perEntities ad ogni chiamata del metodo, secondo
> esempio ?
l'Object Context rappresenta in Entity Framework il concetto di "Unit of
Work", presente in ogni O/RM (Session in NH, DataContext in L2SQL). Ciò
premesso, una unit of work dovrebbe avere una durata temporale limitata
al solo tempo strettamente necessario: tipicamente, ciò significa avere
una istanza della UoW per ogni funzione o "blocco" di operazioni. Meglio
quindi l'approccio del secondo esempio. Nel caso specifico di EF, poichè
l'object context implementa IDisposable, puoi usare lo statement using
per "assicurarti" il rilascio delle risorse utilizzate al suo interno
--
.A
GUISA -
http://www.guisa.org
UGIdotNET -
http://www.ugidotnet.org
Read my blog at:
http://blogs.ugidotnet.org/pape


title: metodo corretto con EF

text:
Il 06/02/2011 12:54, Andrea Saltarello ha scritto:
> Il 06/02/11 11.42, Sander ha scritto:
>> In un metodo come questo, che mi restituisce un 'contatto' da un DB
>> fornendo l'id, ï¿œ corretto utilizzare il primo esempio, che utilizza un
>> oggetto di tipo perEntities definito una sola volta in una classe
>> visibile a tutta l'applicazione (classe GV) , oppure ï¿œ necessario
>> reistanziare un oggetto perEntities ad ogni chiamata del metodo, secondo
>> esempio ?
>
> l'Object Context rappresenta in Entity Framework il concetto di "Unit of
> Work", presente in ogni O/RM (Session in NH, DataContext in L2SQL). Ciï¿œ
> premesso, una unit of work dovrebbe avere una durata temporale limitata
> al solo tempo strettamente necessario: tipicamente, ciï¿œ significa avere
> una istanza della UoW per ogni funzione o "blocco" di operazioni. Meglio
> quindi l'approccio del secondo esempio. Nel caso specifico di EF, poichï¿œ
> l'object context implementa IDisposable, puoi usare lo statement using
> per "assicurarti" il rilascio delle risorse utilizzate al suo interno
>
Grazie, quindi secondo esempio con l'aggiunta di 'using'. Anche perche
sto riscontrando un problema enorme col primo approccio, su mysql, per
niente simpatico.
thanks Sander


title: Ottenere un oggetto Exception da una funzione

author: Alessio Forconi

text:
Salve a tutti,
mi sto scontrando con questo scoglio, chiamando una funzione che
aggiorna un db se qualcosa va storto vorrei poter ottenere l'oggetto
Exception per raccogliere in seguito in dati, ma è possibile farlo? Se
si come posso definire la funzoine?
Questo è più o meno ciò che vorrei fare:
private void btnFerieElimina_Click(object sender, EventArgs e)
{
    if (Elimina(viewFerie) == Oggetto Exception)
    {
        Elabora i dati
    }
}
 private ??? Elimina(view)
 {
            return ???
            try
            {
                ...
                ...
                ...
            }
            catch (Exception ex)
            {
                return Exception;
            }
 }
Magari è una cavolata ma non vedo la soluzione.
Grazie


text:
"Alessio Forconi" <
forc...@gmail.com
> wrote in message
news:d598c206-41f4-4385...@c26g2000vbq.googlegroups.com...
> mi sto scontrando con questo scoglio, chiamando una funzione che
> aggiorna un db se qualcosa va storto vorrei poter ottenere l'oggetto
> Exception per raccogliere in seguito in dati, ma � possibile farlo? Se
> si come posso definire la funzoine?
Perche' non l'approccio canonico in cui Elimina fa quello che deve fare (e
nel tuo caso probabilmente ritorna semplicemente void, cioe' l'equivalente
di una sub in vb) e, se un'eccezione viene sollevata, e' nello handler che
fai il try-catch?
BTW, mi consola vedere che non sono l'unico a lavorare di sabato sera...  :)
-LV

--- Posted via news://
freenews.netfront.net/
 - Complaints to
ne...@netfront.net
 ---


title: try-catch miglior pratica

text:
Una applicazione fa un classico uso di un DB server remoto.  Vorrei che
tutti i colloqui col DB fossero 'protetti', ovviamente per avvisare
l'operatore e non mandare in crash l'applicazione perche una qualsiasi
query non ha avuto possibilità di esecuzione.
Qual'è secondo voi il miglior modo di non lasciare questo tipo di falle
in una applicazione?
Proteggere dei macro-metodi con un bel try/catch sulla chiamata, anche
se la funzione magari fa parecchie cose e non siamo in grado di reagire
ad una eccezione che ci viene restituita? Oppure intervenire piu
granularmente, e parare ogni accesso al DB?
O fare uso di unhandled exception a livello applicazione, così 'pariamo
tutto' anche se la possibilità di reagire è pari a 0...
Personalmente impiego molto tempo nello sviluppo per questo aspetto, sul
quale tra l'altro, tendo a tornare in un secondo tempo visto che di
primo acchitto si tende ad andare avanti per vedere i risultati della
logica che implementiamo, e stare nei tempi che ci vengono richiesti.
Apprezzerei molto un consiglio generale, mollte grazie.
Alessandro


title: try-catch miglior pratica

text:
Ciao Sander,
On 2/14/2011 10:26 AM, Sander wrote:
[cut]
> Qual'è secondo voi il miglior modo di non lasciare questo tipo di falle
> in una applicazione?
> Proteggere dei macro-metodi con un bel try/catch sulla chiamata, anche
> se la funzione magari fa parecchie cose e non siamo in grado di reagire
> ad una eccezione che ci viene restituita? Oppure intervenire piu
> granularmente, e parare ogni accesso al DB?
Io opterei per la seconda.
> O fare uso di unhandled exception a livello applicazione, così 'pariamo
> tutto' anche se la possibilità di reagire è pari a 0...
Si chiama Pokémon Exception Handling
http://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined/2349399#2349399
:-)
Io eviterei. Metterei un gestore di eccezioni non gestite a livello di
applicazione per raccogliere un dump utile se malauguratamente la tua
app dovesse esplodere, ma non credo sia un bene affidare a questa
politica la comunicazione degli errori all'utente.
> Personalmente impiego molto tempo nello sviluppo per questo aspetto, sul
> quale tra l'altro, tendo a tornare in un secondo tempo visto che di
> primo acchitto si tende ad andare avanti per vedere i risultati della
> logica che implementiamo, e stare nei tempi che ci vengono richiesti.
Spesso poco tempo significa scarsa qualità. :-)
Scherzi a parte, se il tuo manager ti "impone" uno scarso controllo
sulla qualità del software (niente test, niente log, niente tracciamento
delle eccezioni) e poi in produzione fate una figura pessima, la colpa è
solo sua. E' vero che tu, con la tua "etica da sviluppatore" (TM)
dovresti farglielo notare, ma capisco anche che tante volte è difficile...
HTH,
Giulio
--


title: try-catch miglior pratica

text:
On Feb 14, 9:26 am, Sander <
max...@yahoo.it
> wrote:
> Una applicazione fa un classico uso di un DB server remoto.  Vorrei che
> tutti i colloqui col DB fossero 'protetti', ovviamente per avvisare
> l'operatore e non mandare in crash l'applicazione perche una qualsiasi
> query non ha avuto possibilità di esecuzione.
>
> Qual'è secondo voi il miglior modo di non lasciare questo tipo di falle
> in una applicazione?
> Proteggere dei macro-metodi con un bel try/catch sulla chiamata, anche
> se la funzione magari fa parecchie cose e non siamo in grado di reagire
> ad una eccezione che ci viene restituita? Oppure intervenire piu
> granularmente, e parare ogni accesso al DB?
> O fare uso di unhandled exception a livello applicazione, così 'pariamo
> tutto' anche se la possibilità di reagire è pari a 0...
Per mia esperienza, ci sono fondamentalmente due tipi di eccezioni da
gestire in questo caso: 1) *eventuali* violazioni di data integrity
che possono derivare operazioni di scrittura sul db (violazioni di
constraint, integrita' referenziale, unicita', ecc.); 2) le eccezioni
vere e proprie, per esempio perche' il server non risponde.
Il secondo punto penso sia chiaro, e il gestore puo' essere piu' o
meno ad alto livello, dove il database viene considerato insieme agli
altri servizi di sistema.
Il primo punto e' piu' complesso (anche perche' nel dettaglio dipende
dalla strategia di accesso ai dati, nonche' eventualmente dalla
strategia di mapping), ma l'idea e' che occorre gestire solo le
*eccezioni by design*, non le eventuali altre eccezioni che in questo
caso sono piuttosto difetti (bug) del software.
Ad esempio, una strategia base per l'unicita' delle email registrate
e' gestire l'eccezione sollevata dal database a causa della violazione
del constraint relativo. Tali gestori sono poi tanto granulari quanto
lo e' il tuo data access layer... ovvero si puo' fare lo stesso
livello di astrazione. Di base, SqlServer come minimo ritorna codici
di errore.
> Personalmente impiego molto tempo nello sviluppo per questo aspetto, sul
> quale tra l'altro, tendo a tornare in un secondo tempo visto che di
> primo acchitto si tende ad andare avanti per vedere i risultati della
> logica che implementiamo, e stare nei tempi che ci vengono richiesti.
Assumendo che la strategia di accesso ai dati sia abbastanza uniforme
nel tempo, questo aspetto si puo' via via astrarre e diventare parte
integrante del codice di libreria.
-LV


title: try-catch miglior pratica

text:
On Feb 14, 10:17 am, Giulio Petrucci <sis...@nonono.boh> wrote:
> On 2/14/2011 10:26 AM, Sander wrote:
>
> > Qual'è secondo voi il miglior modo di non lasciare questo tipo di falle
> > in una applicazione? [...]
>
> > Personalmente impiego molto tempo nello sviluppo per questo aspetto, sul
> > quale tra l'altro, tendo a tornare in un secondo tempo visto che di
> > primo acchitto si tende ad andare avanti per vedere i risultati della
> > logica che implementiamo, e stare nei tempi che ci vengono richiesti.
>
> Spesso poco tempo significa scarsa qualità. :-)
Troppo spesso e' vero! In quella equazione va anche considerato lo
*scope*.
-LV


title: try-catch miglior pratica

text:
Sander wrote:
> Una applicazione fa un classico uso di un DB server remoto.  Vorrei che tutti
> i colloqui col DB fossero 'protetti', ovviamente per avvisare l'operatore e
> non mandare in crash l'applicazione perche una qualsiasi query non ha avuto
> possibilità di esecuzione.
Una strategia che paga molto ed è "pulita" è quella di usare le
Action<T> con lambda.
Es:
public bool ExecuteActionOnDB(Action<SqlConnection> connectionAction)
{
 try
 {
  if(connectionAction == null)
   throw new ArgumentNullException(connectionAction);
  using(var cnn = new SqlConnection(...)
  {
   cnn.Open(); // close fatta dalla using
   connectionAction(cnn);
  }
 }
 catch(Exception err)
 {
  Log(err);
  return false;
 }
}
A questo punto hai centralizzato il punto in cui crei e usi la
connection.
Per usarla ovunque fai così:
bool res = ExecuteActionOnDB(cnn => {
  var myCommand = GetCommand(...);
  myCommand.Connection = cnn;
  myCommand.Execute...
});
if(!res) ==> avvisi l'utente che qualcosa è andato storto
if(res)  ==> presenti i dati
ovviamente nel comunicare che c'è stato un errore non devi mai dare i
dettagli dell'eccezione ma solo loggarti e spedirti un'email.
--
Raffaele Rialdi
http://www.iamraf.net
Weblog:
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET -
http://www.ugidotnet.org/


title: try-catch miglior pratica

text:
Ciao Raf,
tutto chiarissimo, ma c'è una scelta strategica che mi sfugge:
On 2/15/2011 10:03 AM, Raffaele Rialdi [MVP] wrote:
> ovviamente nel comunicare che c'è stato un errore non devi mai dare i
> dettagli dell'eccezione ma solo loggarti e spedirti un'email.
Perché?
Ciao,
Giulio
--


title: try-catch miglior pratica

text:
Giulio Petrucci wrote:
> Ciao Raf,
>
> tutto chiarissimo, ma c'ï¿œ una scelta strategica che mi sfugge:
>
> On 2/15/2011 10:03 AM, Raffaele Rialdi [MVP] wrote:
>> ovviamente nel comunicare che c'ï¿œ stato un errore non devi mai dare i
>> dettagli dell'eccezione ma solo loggarti e spedirti un'email.
>
> Perchï¿œ?
Perchï¿œ gli errori possono contenere dettagli che forniscono importanti
spunti per l'hacker di turno.
ï¿œ uno dei punti di forza del google hacking:
http://en.wikipedia.org/wiki/Google_hacking
Questi simpatici ragazzi stanno tenendo un database degli errori di cui
andare a caccia, in quanto rivelano informazioni che possono essere
utilizzate per fare hacking:
http://www.exploit-db.com/google-dorks/7/
Esempio di un "Divide by zero":
http://www.exploit-db.com/ghdb/1339/
E dico simpatici in senso positivo perchï¿œ la comunitï¿œ di hacker ï¿œ
l'unica che contribuisce a 360 gradi a mettere alla luce i problemi e a
renderci consapevoli (per chi vuole ascoltare, ovviamente).
E btw ï¿œ anche una delle raccomandazioni della SDL (Security Development
Lifecycle) che ï¿œ apprezzato anche al di fuori del mondo MS.



title: try-catch miglior pratica

text:
Ciao Raf,
On 2/15/2011 1:16 PM, Raffaele Rialdi [MVP] wrote:
> Perché gli errori possono contenere dettagli che forniscono importanti
> spunti per l'hacker di turno.
[cut]
Perfetto.
Grazie,
Giulio
--


title: try-catch miglior pratica

text:
On Feb 15, 9:03 am, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
>
wrote:
> Sander wrote:
> > Una applicazione fa un classico uso di un DB server remoto.  Vorrei che tutti
> > i colloqui col DB fossero 'protetti', ovviamente per avvisare l'operatore e
> > non mandare in crash l'applicazione perche una qualsiasi query non ha avuto
> > possibilità di esecuzione.
>
> Una strategia che paga molto ed è "pulita" è quella di usare le
> Action<T> con lambda.
La definirei piu' precisamente una "strategia di coding", altrimenti
ci si confonde...
> Es:
>
> public bool ExecuteActionOnDB(Action<SqlConnection> connectionAction)
> {
>  try
>  {
>   if(connectionAction == null)
>    throw new ArgumentNullException(connectionAction);
>
>   using(var cnn = new SqlConnection(...)
>   {
>    cnn.Open(); // close fatta dalla using
>    connectionAction(cnn);
>   }
>  }
>  catch(Exception err)
>  {
>   Log(err);
>   return false;
>  }
> }
>
> A questo punto hai centralizzato il punto in cui crei e usi la
> connection.
Si', ma cio' che hai guadagnato e' un gestore del tutto generico, che
al limite si presta a gestire le eccezioni che nel mio post iniziale
metto sotto il punto 2. In piu', in un'applicazione reale, l'accesso
al log come minimo dovrebbe essere iniettato, per cui torniamo al
fatto che le eccezioni generiche andrebbero piuttosto gestite ad alto
livello (il catch della generica Exception e' infatti una bad practice
se non e' fatto top level). -- Ovviamente, sullo scheletro che
presenti si puo' costruire anche altro, e persino tutt'altro, ma cosi'
come lo presenti mi sembra che sia piu' fuorviante che altro.
-LV


title: try-catch miglior pratica

text:
LudovicoVan wrote:
>> Una strategia che paga molto ed è "pulita" è quella di usare le
>> Action<T> con lambda.
>
> La definirei piu' precisamente una "strategia di coding", altrimenti
> ci si confonde...
Beh scrivendo del codice ... :)
> Si', ma cio' che hai guadagnato e' un gestore del tutto generico, che
> al limite si presta a gestire le eccezioni che nel mio post iniziale
> metto sotto il punto 2. In piu', in un'applicazione reale, l'accesso
> al log come minimo dovrebbe essere iniettato,
Quello è uno schema che ho scritto al volo nel post per dare l'idea,
mica la voglio mettere in System.Data....
Iniettare un sistema di logging è un lavoro molto veloce e che comunque
non è il topic del thread.
Il discorso di fondo è di provvedere nel proprio DAL ad uno o più
sistemi centralizzati per accedere al db e gestire le eccezioni.
E questo ti evita di spargere da tutte le parti aperture e chiusure di
connessioni.
Proseguendo con lo stesso concetto si può scrivere analogo codice per
la using di un datareader, ottenendo la composizione a pipeline tipica
dei linguaggi funzionali che rende più leggibile e manutenibile il
codice.
> per cui torniamo al
> fatto che le eccezioni generiche andrebbero piuttosto gestite ad alto
> livello (il catch della generica Exception e' infatti una bad practice
> se non e' fatto top level). --
E qui possiamo anche discuterne perché la trap della sola SqlException
rischia di propagare indietro altri tipi di eccezioni (security,
invalidoperation, nullref, etc.) che sarebbe più difficile ricondurre
al DAL.
La gestione dell'eccezione puntuale è un ottima cosa *se* sai cosa
fartene (recovery dell'eccezione, generazione di una
applicationexception, logging, etc.). Ma quando sai che è muore lì, la
propagazione indietro e la conseguente gestione a livello più alto,
diventa un incubo diagnostico.
> Ovviamente, sullo scheletro che
> presenti si puo' costruire anche altro, e persino tutt'altro, ma cosi'
> come lo presenti mi sembra che sia piu' fuorviante che altro.
Gli esempi servono a rendere l'idea, non a fare cut&paste in codice di
produzione.



title: try-catch miglior pratica

text:
On Feb 16, 7:51 pm, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
>
wrote:
> LudovicoVan wrote:
> >> Una strategia che paga molto ed è "pulita" è quella di usare le
> >> Action<T> con lambda.
>
> > La definirei piu' precisamente una "strategia di coding", altrimenti
> > ci si confonde...
>
> Beh scrivendo del codice ... :)
Bah, nell'ambito del thread presente mi sembrava piu' che altro la
solita mockery alla precisione del sottoscritto: altrimenti ti devo
dare dell'impreciso.
> > Si', ma cio' che hai guadagnato e' un gestore del tutto generico, che
> > al limite si presta a gestire le eccezioni che nel mio post iniziale
> > metto sotto il punto 2. In piu', in un'applicazione reale, l'accesso
> > al log come minimo dovrebbe essere iniettato,
>
> Quello è uno schema che ho scritto al volo nel post per dare l'idea,
> mica la voglio mettere in System.Data....
> Iniettare un sistema di logging è un lavoro molto veloce e che comunque
> non è il topic del thread.
> Il discorso di fondo è di provvedere nel proprio DAL ad uno o più
> sistemi centralizzati per accedere al db e gestire le eccezioni.
> E questo ti evita di spargere da tutte le parti aperture e chiusure di
> connessioni.
> Proseguendo con lo stesso concetto si può scrivere analogo codice per
> la using di un datareader, ottenendo la composizione a pipeline tipica
> dei linguaggi funzionali che rende più leggibile e manutenibile il
> codice.
Va tutto (piu' o meno) bene, per le connessioni come per i datareader:
sicuramente non per le eccezioni, dove il tuo esempio e poi discorso
resta, appunto, tanto approssimativo quanto fuorviante.
> > per cui torniamo al
> > fatto che le eccezioni generiche andrebbero piuttosto gestite ad alto
> > livello (il catch della generica Exception e' infatti una bad practice
> > se non e' fatto top level). --
>
> E qui possiamo anche discuterne perché la trap della sola SqlException
> rischia di propagare indietro altri tipi di eccezioni (security,
> invalidoperation, nullref, etc.) che sarebbe più difficile ricondurre
> al DAL.
> La gestione dell'eccezione puntuale è un ottima cosa *se* sai cosa
> fartene (recovery dell'eccezione, generazione di una
> applicationexception, logging, etc.). Ma quando sai che è muore lì, la
> propagazione indietro e la conseguente gestione a livello più alto,
> diventa un incubo diagnostico.
E di nuovo quello che dici e', IMO, tanto approssimativo quanto
fuorviante: ci sono guidelines e non dicono quello che tu dici (che e'
per lo piu' semplicemente incongruente), ma soprattutto la parolina
magica qui e' appunto *gestione*, con tutto cio' che ne e' implicato.
C'era un ottimo articolo da qualche parte su MSDN realitivo alle
strategie di exception handling, ma non riesco a ritrovarlo adesso.
Provvisoriamente ho trovato questo:
http://msdn.microsoft.com/en-us/library/ff648001.aspx
-- Per esempio, il paragrafo "When to Catch Exceptions" recita: << A
method should catch exceptions only when it has to perform one or more
of the following actions: Gather information for logging. Add any
relevant information to the exception. Execute cleanup code. Try to
recover. If a particular method does not have to perform one or more
of these actions, the method should not catch the exception. Instead,
it should allow the exception to propagate back up the call stack.
This keeps your code clean and explicit because each method catches
only those exceptions that must be handled within the scope of that
particular method and allows all other exceptions to continue to
propagate. >> E cosi' via... qui siamo all'ABC.
> > Ovviamente, sullo scheletro che
> > presenti si puo' costruire anche altro, e persino tutt'altro, ma cosi'
> > come lo presenti mi sembra che sia piu' fuorviante che altro.
>
> Gli esempi servono a rendere l'idea, non a fare cut&paste in codice di
> produzione.
Certo: e -IMO- il tuo esempio (nonche' il discorso che ne e' seguito)
rende appunto un'idea...  sbagliata! :)
-LV


title: try-catch miglior pratica

text:
LudovicoVan wrote:
> E di nuovo quello che dici e', IMO, tanto approssimativo quanto
> fuorviante: ci sono guidelines e non dicono quello che tu dici (che e'
> per lo piu' semplicemente incongruente), ma soprattutto la parolina
> magica qui e' appunto *gestione*, con tutto cio' che ne e' implicato.
>
> C'era un ottimo articolo da qualche parte su MSDN realitivo alle
> strategie di exception handling, ma non riesco a ritrovarlo adesso.
> Provvisoriamente ho trovato questo:
>
http://msdn.microsoft.com/en-us/library/ff648001.aspx
 -- Per esempio, il
> paragrafo "When to Catch Exceptions" recita: << A method should catch
> exceptions only when it has to perform one or more of the following actions:
> Gather information for logging. Add any relevant information to the
> exception. Execute cleanup code. Try to recover. If a particular method does
> not have to perform one or more of these actions, the method should not catch
> the exception. Instead, it should allow the exception to propagate back up
> the call stack. This keeps your code clean and explicit because each method
> catches only those exceptions that must be handled within the scope of that
> particular method and allows all other exceptions to continue to
> propagate. >> E cosi' via... qui siamo all'ABC.
Quello che citi fornisce solo una guideline su quando gestire o meno
un'eccezione ... e questo non coccia affatto con quanto scrivevo.
Io ci andrei piano con le interpretazioni di cose scritte da altri...
> Certo: e -IMO- il tuo esempio (nonche' il discorso che ne e' seguito)
> rende appunto un'idea...  sbagliata! :)
Considerato che:
- la propagazione del vero motivo l'eccezione fino alla UI ï¿œ da
scartare per motivi di sicurezza
- il logging ce lo puoi mettere come ti pare
Quel codice ti para da questi problemi che sono generici per natura.
Totalmente diverso ï¿œ l'errore dovuto ad una logica come il mapping o la
concorrenza che *non* deve essere propagato in quanto tale per motivi
di sicurezza ed anche perchï¿œ potrebbero verificarsi anche in totale
assenza di un'eccezione di basso livello.
Perciï¿œ, che si tratti di una dbconcurrencyexception o di un errore
nello strato di logica, questi sono errori di natura totalmente
differenti che devono essere generati come scelta architetturale e che
nulla hanno a che fare con le eccezioni come la sqlexception.
In questi casi infatti si usano application exception (re-throw se
generate da un'eccezione di piï¿œ basso livello o generate direttamente
dal nostro codice).



title: try-catch miglior pratica

text:
On Feb 16, 10:08 pm, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
>
wrote:
> Io ci andrei piano con le interpretazioni di cose scritte da altri...
Le mie non erano interpretazioni, bensi' obiezioni: continui ad essere
impreciso e fuorviante.
> Considerato che:
> - la propagazione del vero motivo l'eccezione fino alla UI da
> scartare per motivi di sicurezza
> - il logging ce lo puoi mettere come ti pare
> Quel codice ti para da questi problemi che sono generici per natura.
Quel codice risolve problemi che a rigore semplicemente non sono
quelli. E, come nota a margine, "propagazione" e' concetto diverso da
"visualizzazione all'utente".
> Totalmente diverso l'errore dovuto ad una logica come il mapping o la
> concorrenza [...]
> che si tratti di una dbconcurrencyexception o di un errore
> nello strato di logica, questi sono errori di natura totalmente
> differenti che devono essere generati come scelta architetturale e che
> nulla hanno a che fare con le eccezioni come la sqlexception.
Si': avevo fatto una serie di considerazioni di base, su certe
differenze fondamentali, nel mio primo post in questo thread. Magari
avresti potuto espandere a partire da quello, per maggiore precisione
nonche' per una collaborazione piu' fruttuosa... ma questa e' solo una
mia personale opinione.
-LV


title: try-catch miglior pratica

text:
LudovicoVan wrote:
> Le mie non erano interpretazioni, bensi' obiezioni: continui ad essere
> impreciso e fuorviante.
Hai citato quell'articolo a sproposito.
> Quel codice risolve problemi che a rigore semplicemente non sono
> quelli. E, come nota a margine, "propagazione" e' concetto diverso da
> "visualizzazione all'utente".
Che però era il topic dell'intero thread
> Si': avevo fatto una serie di considerazioni di base, su certe
> differenze fondamentali, nel mio primo post in questo thread. Magari
> avresti potuto espandere a partire da quello, per maggiore precisione
> nonche' per una collaborazione piu' fruttuosa... ma questa e' solo una
> mia personale opinione.
La collaborazione è possibile se il tono è disteso, cosa che tu non
concedi quasi mai nei tuoi post.
Se cambiassi atteggiamento sarebbe certamente possibile.
Per contro il mio post iniziale non rappresentava affatto uno scontro
con quanto da te affermato precedentemente.
Poi però te le vai a cercare ...



title: try-catch miglior pratica

text:
On Feb 16, 11:19 pm, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
>
wrote:
> LudovicoVan wrote:
> Hai citato quell'articolo a sproposito.
Non direi proprio, ma come al solito ai posteri: cercare il mio post
originale e trarre le proprie conclusioni.
> > Quel codice risolve problemi che a rigore semplicemente non sono
> > quelli. E, come nota a margine, "propagazione" e' concetto diverso da
> > "visualizzazione all'utente".
>
> Che però era il topic dell'intero thread
E' la tua proposta/approccio che critico, non il topic del thread.
> > Si': avevo fatto una serie di considerazioni di base, su certe
> > differenze fondamentali, nel mio primo post in questo thread. Magari
> > avresti potuto espandere a partire da quello, per maggiore precisione
> > nonche' per una collaborazione piu' fruttuosa... ma questa e' solo una
> > mia personale opinione.
>
> La collaborazione è possibile se il tono è disteso, cosa che tu non
> concedi quasi mai nei tuoi post.
Te lo concedo: ma e' che a me occorre una base di
onesta' (intellettuale) su cui distendersi.
-LV


title: try-catch miglior pratica

text:
> Il discorso di fondo è di provvedere nel proprio DAL ad uno o più
> sistemi centralizzati per accedere al db e gestire le eccezioni.
> E questo ti evita di spargere da tutte le parti aperture e chiusure di
> connessioni.
Scusate se interrompo una discussione tra persone sicuramente
preparatissime, ma tornando al mero codice mi soffermo su questo punto
sopra, che seguivo anch'io utilizzando il precendente e versatilissimo
ado.net
 (sqlConnection, sqlCommand..etc). E' che non riesco ancora a
realizzarlo utilizzando EF. Se ad esempio data una entity ( una tabella)
voglio indietro un oggetto corrispondente ad un ID, come posso rendere
questo piccolo metodo universale,  cioe valido per N tabelle diverse?
Cosa metto nella linq select?
Grazie.....Alessandro


title: try-catch miglior pratica

text:

Con EF4 hai un context che implementa IDisposable quindi puoi costruire
un pattern analogo dove hai la using del context all'interno di una
try/catch.
Al posto della connection la lambda vede il context e tutto il resto
dei discorsi è uguale.
Con gli OR/M il numero di situazioni in cui l'errore è di logica e non
tecnologico cresce. In altre parole puoi avere eccezioni lanciate da
EF4 così come errori di logica (non eccezioni) dovuti alla complessità
del grafo che stai persistendo/leggendo.
Ripetendo il discorso che ho già scritto, ha senso centralizzare la
gestione dell'errore "tecnologico" fermo restando che ha anche senso
che tu lanci (generando o rilanciando) eccezioni che siano
application-specific.
Ma queste ultime sono scelte architetturali che vanno fatte in
qualsiasi layer dell'applicazione e prescindono dal DAL in quanto tale.
