IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La FAQ ASP.NET C#
374 réponses à vos questions dont 28 nouvelles et plusieurs mises à jour

Le , par nico-pyright(c)

21PARTAGES

0  0 
Vous trouverez ci-dessous, le lien de la faq dédiée à ASP.NET en C# :
http://dotnet.developpez.com/faq/asp/csharp

Mise à jour 12/10/2009 :
- Refonte du plan de la FAQ
- Mise à jour de questions/réponses obsolètes
- Ajout de 28 nouvelles questions/réponses

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 14/10/2009 à 1:53
énorme

0  0 
Avatar de Immobilis
Expert éminent https://www.developpez.com
Le 14/10/2009 à 22:29
Merci beaucoup pour le boulot

Petite question, est-ce qu'on ne devrait pas faire un Application.Lock() avant de créer ou mettre à jour une variable d'application (FAQ)?

A+
0  0 
Avatar de nico-pyright(c)
Rédacteur https://www.developpez.com
Le 15/10/2009 à 8:56
si, tu as tout à fait raison.

A part si cela se passe dans la méthode Application_Start, il est recommandé d'utiliser Lock et Unlock lors de la mise à jour d'une valeur dans un objet succeptible d'être partagé par plusieurs thread.

Tout dépend bien sur de la sémantique de la valeur.

Je mettrais à jour la Q/R pour prendre en compte ta remarque, merci
0  0 
Avatar de Immobilis
Expert éminent https://www.developpez.com
Le 15/10/2009 à 20:32
Citation Envoyé par nico-pyright(c) Voir le message
Tout dépend bien sur de la sémantique de la valeur.
C'est à dire? A la place des variables d'application on peut évidement utiliser les les variables statiques. Et je me demandais si le pattern singleton était toujours d'actualité (framework 3.5) pour ce type de variables?

A+
0  0 
Avatar de nico-pyright(c)
Rédacteur https://www.developpez.com
Le 16/10/2009 à 9:15
je pensais au sens de la valeur.

C'est à dire que si tu vas stocker un compteur de nombre de pages vues, ou de visites, etc ... ca a complétement son sens d'utiliser un lock.

si c'est pour stocker la date de la dernière page vue ou un truc qui se moque un peu de s'il est accédé par plusieurs thread à la fois, c'est pas la peine de vérouiller.

Pour ma part, je n'utilise pas le pattern singleton pour se genre d'accès, je préfère me baser sur un contexte http.
0  0 
Avatar de Immobilis
Expert éminent https://www.developpez.com
Le 16/10/2009 à 22:33
Et un dictionnaire de entier/chaine en lecture seule?
0  0 
Avatar de nico-pyright(c)
Rédacteur https://www.developpez.com
Le 19/10/2009 à 9:02
en lecture seule ? Tu veux donc un dictionnaire de "constantes globales" ?

C'est de toutes facons redondant à mon avis avec l'objet d'application.
0  0 
Avatar de Immobilis
Expert éminent https://www.developpez.com
Le 19/10/2009 à 21:09
Citation Envoyé par nico-pyright(c) Voir le message
en lecture seule ? Tu veux donc un dictionnaire de "constantes globales" ?
C'est un peu ça.
Citation Envoyé par nico-pyright(c) Voir le message
C'est de toutes facons redondant à mon avis avec l'objet d'application.
Les variables statiques ne serait-elles pas plus stables?
0  0 
Avatar de nico-pyright(c)
Rédacteur https://www.developpez.com
Le 20/10/2009 à 9:51
si elles n'ont pas vocations à bouger, tu peux effectivement utiliser des variables statiques.
Si tu dois parfois les mettre à jour dans un contexte multithread, ca peut devenir problèmatique.
0  0 
Avatar de Immobilis
Expert éminent https://www.developpez.com
Le 20/10/2009 à 19:25
Ok merci
0  0