2009-12-04 5 views
1

Dans mon code, je vérifie si un fichier existe et le stocke dans l'objet Application dans asp.net. Par la suite, j'accède à ce booléen pour faire quelque chose dans mon service Web.Simulation d'une application dans WCF

Maintenant, je veux réécrire mon service Web dans wcf et les choses sont différentes ici. L'objet application n'existe pas. Quelle est la meilleure façon d'effectuer cette tâche: Lors du démarrage de l'application du site Web, enregistrez un booléen. passer à mon WCF il sait quand il appelle une fonction (sans le booléen faisant partie des paramètres de la méthode)

Répondre

1

Le dernier message here offre une option de partage d'état entre les appels:

Les classes statiques existent toujours pour la durée de vie de l'application. Ils sont utiles dans WCF pour maintenir l'état parce qu'ils ne sont pas réinstanciés chaque fois qu'un appel ou une nouvelle connexion WCF est faite.

+1

L'état statique devrait être banni de tous les langages de programmation. –

+1

Point pris. Comme tous les marteaux, avec des caractéristiques statiques, vous pouvez construire une maison ou casser votre pouce. –

1

Beaucoup de gens ne réalisent pas que WCF prend en charge les modèles d'injection de dépendance (DI) tels que Constructor injection sans trop de tracas.

Définissez une classe qui encapsule la connaissance (le booléen) que vous voulez connaître et injectez une instance de cette classe dans votre service WCF et interrogez-la sur la valeur (et tout ce que vous voulez savoir).

Si vous ciblez la classe injectée comme un objet à long terme (généralement appelé Singleton, mais à ne pas confondre avec le modèle de conception Singleton) vous pouvez continuer à lui demander sur la valeur et vous obtiendrez le même réponse à chaque fois.

Parmi beaucoup d'autres choses, this post décrit comment injecter des dépendances dans une implémentation de service WCF lorsqu'il n'a pas de constructeur par défaut.

1

L'objet Application dans ASP.NET est principalement nécessaire pour la rétrocompatibilité avec les applications ASP classiques.

Il s'agit essentiellement d'un Dictionary<string, object> statique avec une sémantique de verrouillage compatible avec ASP classique.

Vous pouvez facilement le remplacer en stockant votre état à l'échelle de l'application dans n'importe quel champ statique approprié, en fournissant votre propre verrouillage si nécessaire. Ensuite, vous n'avez pas besoin de vous inquiéter si vous utilisez une application ASP.NET, une application WCF ou autre chose.