1

Je travaille sur une application Web qui utilise un couple de services pour synchroniser des données avec des ressources externes. L'application et les services partagent la même couche de données et utilisent Castle Windsor pour implémenter l'IoC.Limite de la durée de vie de l'instance à une seule itération

Dans l'application Web, il existe un mode de vie PerWebRequest qui limite la durée de vie d'une instance à la durée de vie d'une demande. Je veux utiliser quelque chose de similaire dans les services. Les services sont déclenchés de temps en temps pour effectuer la synchronisation. Je souhaite que les services et les référentiels de la couche de données soient des singletons au sein d'une même itération du service, similaire au style de vie PerWebRequest dans l'application Web.

Ce que j'ai trouvé est le concept d'un Run. Une exécution est une invocation unique du code de synchronisation dans le service. Cela ressemble à ceci:

using(_runManager.Run()) 
    { 
     var sync = _usageRepoFactory.CreateInstance(); 
     sync.SynchronizeUsage(); 
    } 

La mise en œuvre de IRun libérera tous les cas avec le PerRunLifeStyle résolu depuis sa création quand il est disposé, à la fin du bloc using. Ce code a l'air assez propre, mais je me demande s'il existe une meilleure façon de procéder. J'ai essayé d'utiliser des contenants pour enfants, mais je les ai trouvés plutôt «lourds» après le profilage de la solution.

Tout commentaire est le bienvenu. Si nécessaire, je peux également publier l'implémentation IRun.

Mise à jour

Sur la base des commentaires que j'ai nettoyé un peu le code. J'ai introduit un nouveau service IRunManager qui est fondamentalement une usine pour IRun. J'ai également commencé à utiliser une usine pour se débarrasser de l'invocation ServiceLocator.

+0

est-ce que nous parlons des services WCF? WCF Facility a un style de vie par-wcf-opération. N'utilisez pas non plus le conteneur comme localisateur de service! –

+0

@Krzysztof Ce sont des services de fenêtres «classiques». Je ne suis pas sûr de ce que vous voulez dire quand vous dites que je ne devrais pas utiliser le conteneur comme localisateur de service. –

+0

RE: Service Locator -> Voir: http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx – PatrickSteele

Répondre