[ASP.NET] Oggetti globali all'applicazione

[0rph3n]

Ciao ragassuoli,
non è che qualcuno saprebbe dirmi se c'è la possibilità di creare degli oggetti globali a livello di application usabili da tutte le sessioni?
e magari anche come fare?!

grassie :D

[0rph3n]

bon, penso di aver trovato da me!
in teoria se istanzio uno oggetto nell'Application_Start del Global.asax il suo scope è tutta l'applicazione...
aspetto conferme ed intanto provo!

[giannola]

bon, penso di aver trovato da me!
in teoria se istanzio uno oggetto nell'Application_Start del Global.asax il suo scope è tutta l'applicazione...
aspetto conferme ed intanto provo!

certo.

di solito là creo un oggetto application("nome") che contiene la stringa di connessione al db.

[0rph3n]

io ci voglio istanziare il mio pool di connessioni :)
per quanto riguarda le classi statiche come funziona?
insomma le classi statiche non hanno costruttore, quindi non possono essere istanziate, potrei quindi avere una classe statica che ha come scope l'application?

[Einstein]

Per rendere accessibile un'istanza "globalmente" a tutta l'applicazione, puoi usare il pattern Singleton:

http://www.dofactory.com/Patterns/PatternSingleton.aspx

che è una cosa diversa, ma secondo me migliore (quantomeno più Object-Oriented), di Application().

Ciao

[cionci]

Per rendere accessibile un'istanza "globalmente" a tutta l'applicazione, puoi usare il pattern Singleton:
Usare il singleton è come sparare ad una mosca con un cannone. A parte le disquisizioni teniche sull'utilità di questo pattern (ma come, nella OOP abbiamo fatto di tutto per eliminare le variabili globali e le riaggiungiamo con un trucco ?), se ASP mette a disposizione un metodo di accesso alle variabili globali d'applicazione non vedo perchè non usarlo ;)

PS: il fatto che sia meglio non utilizzare o comunque non abusare del pattern singleton non me lo sono inventato, sta scritto su diversi libri. Basti citare Kent Beck e gli stessi GoF.

[Einstein]

Hai ragione Cionci, ma ho proposto Singleton solo come alternativa ad Application().
ASP.NET permette di ovviare ad Application() e Session() in diversi modi, ma il problema è la variabile globale in se, più che il modo che usi per ottenerla. Personalmente, tra i due metodi preferisco Singleton. ;)

Ciao

[cionci]

Premetto che ho programmato in ASP, ma non in ASP.Net...quindi parlo con le conoscenze che ho di ASP...
Sinceramente mi sembra più "omogeneo" l'uso di Application. Se la piattaforma te lo permette perchè usare trucchi per ottenere una variabile globale ?

[giannola]

Premetto che ho programmato in ASP, ma non in ASP.Net...quindi parlo con le conoscenze che ho di ASP...
Sinceramente mi sembra più "omogeneo" l'uso di Application. Se la piattaforma te lo permette perchè usare trucchi per ottenere una variabile globale ?
io uso application in asp.net per trovare eventuali percorsi del db access.
Così in pratica posso usare un db di grandi prestazioni (sql server) per immagazzinamento dati utenti, carrelli acquisti, ecc.
E access per fare cazzatelle di secondo ordine tipo menu e sottomenu a tendina con voci dal db e cosette così. :D
così magari un'application la uso per la stringa di connessione a sql server e un altra per fare la stringa col server.mappath del db access. :D

[Einstein]

ASP.NET mette a disposizione il ViewState, la Cache e HttpContext, quindi Session() e Application passano un po' in secondo piano (tant'è che in ASP.NET 2.0 il global.asax non è nemmeno incluso di default nel progetto web).
Per quanto riguarda le connection strings, il file di configurazione (web.config) è lì apposta (in ASP.NET 2.0 è prevista una sezione dedicata esclusivamente alle connection strings).

Ciao

[eve]

vorrei aggiungere una cosa:
invece che usare application usate la proprietà cache per diversi motivi...la piu importante è che è thread safe !
:oink:

[0rph3n]

mille grazie ragazzi :)

[Einstein]

vorrei aggiungere una cosa:
la piu importante è che è thread safe !
:oink:

Questo mi sembra un ottimo motivo... ;)

[0rph3n]

per quanto riguarda le classi statiche come funziona?
insomma le classi statiche non hanno costruttore, quindi non possono essere istanziate, potrei quindi avere una classe statica che ha come scope l'application?
mi quoto e mi rispondo, nella speranza che possa essere utile a qualcuno che ha il mio stesso dubbio.
Fonte: http://www.developersdex.com - Question about static classes in ASP.Net 2.0 (http://www.developersdex.com/asp/message.asp?p=1116&ID=%3Cyqtah.622%24Py2.222%40newssvr27.news.prodigy.net%3E)

Suppose an ASP.Net project contains a public static class with public
methods and members that are used throughout the application. Of course
being static, there is only copy of the class within the application.

Now suppose two users access the Web site simultaneously. Does each
user see his/her own single copy of the static class, or do they
share the class, thus creating a problem that can only be solved
if one use blocks the other while using resources in the static
class?

***************************************************

when you create A static class. Only One copy remain in the Application
so far this is clear.
But do they share same copy or do they have different copy of them? The
answer is Yes they share the same copy of a static class.

***************************************************

Actually, additionally to Masudur's answer, the static members or
classes are shared not only throughout the Web application, but
throughout the process. Since all the web applications run inside one
single process, it means that static classes and members are shared
between different web applications running on the same server. This is
why you have to handle them with a lot of care.

If you want to save variables inside the web application, but not share
them with other web applications, you use the Application collection
(similar to the Session collection).

***************************************************

This is close but not correct. Static things are 1 per AppDomain (as
marshalling is too expensive across them to do it by default).
ASP.net starts each web application in its own app domain, therefore .net
web applications will not share static objects.


Riassumendo (e traducendo)
di oggetti dichiarati static ce n'è UNO per ogni AppDomain e quindi enne ipotetiche sessioni avrebbero tutte a che fare con lo stesso oggetto!

'iao