0

J'ai une question simple. Je suis plus récent avec UnityContainer de Miscrosoft. J'écris une application ASP.NET MVC avec Unity for DI. Ai-je un CONTENEUR différent pour chaque utilisateur connecté à mon application Web? Ou le CONTAINER est le même pour tous les utilisateurs? Donc, si je résous la durée de vie d'un objet avec ContainerControlledLifetimeManager, cela signifie-t-il que seulement pour une session d'utilisateur cet objet est toujours le même?Conteneur Unity dans ASP.NET MVC

J'espère que vous comprenez.

Merci, Christian

+0

'J'écris une application ASP.NET MVC avec Unity for DI.' - Notez que le projet Unity est mort. Pour les nouvelles applications, il est préférable d'utiliser l'un des [nombreux autres conteneurs] (https://github.com/danielpalme/IocPerformance) qui sont toujours actifs. – NightOwl888

+0

Vraiment? Quel est le meilleur pour les applications .net? Je dois également mettre en œuvre des préoccupations transversales. Autofac? –

Répondre

1

à vie fait référence à la vie de l'objet créé par le processus de DI. Par demande, chaque requête obtient son propre objet. Si l'objet dépend de l'utilisateur en cours, les valeurs de chaîne de requête sur cette requête ou les valeurs/présence d'en-têtes de demande une durée de vie PerRequest est appropriée. Si vous avez des paramètres qui varient en fonction de l'emplacement de votre service, par exemple, vous avez enregistré des valeurs à partir de web.config, puis le conteneur est probablement créé dans global.asa et ces objets peuvent vivre tant que le conteneur existe.

Un exemple concret:

Vous avez un service dans le cadre de votre site et vous migrez à vNext de ce service. Les utilisateurs peuvent s'inscrire en cliquant sur un lien qui inclut un paramètre tel que &myService=vNext pour voir le nouveau comportement. Votre méthode Factory utilise la valeur de ce paramètre pour sélectionner vNow ou vNext pour chaque requête.

Voici un code pseudo pour vous aider à démarrer:

container.RegisterInstance<IProductFactory>("enterprise", new EnterpriseProductFactory()); 
container.RegisterInstance<IProductFactory>("retail", new RetailProductFactory()); 
container.RegisterVersionedServiceFactory<IProductFactorySettings, IProductFactory>(); 

Dans cet exemple RegisterVersionedServiceFactory est une méthode d'extension qui ne fait rien, mais décider lequel des instances IProductFactory à utiliser pour la demande actuelle. L'usine fournit l'instance actuelle (il n'y en a que deux pour la durée de vie du service) à utiliser pour cette requête (milliers par seconde).

Ce motif est ce qui rend un très grand site que vous avez probablement utilisé récemment à la fois très stable et très flexible. Les nouvelles versions de services sont déployées en utilisant exactement le même modèle pour garder le site très stable.

+0

Je veux dire que si je résous avec ContainerControlledLifetimeManager un objet pour la connexion à la base de données cet objet est-il le même pour tous les clients connectés à mon application wep? –

+0

La réponse est que ça dépend. Je pense généralement qu'il est souhaitable de partager des connexions afin que votre base de données fonctionne mieux. conversation totalement différente. Je devrais creuser plus profondément dans notre code que j'ai fait pour voir mais mon conseil est d'essayer simplement les différents types d'enregistrement. Créez un objet qui a un nombre d'utilisations, enregistrez-le de multiples façons et demandez à chaque chose que vous récupérez son nombre d'utilisations. Si c'est toujours le cas, vous avez une usine qui en crée une par requête. Si elle augmente sur chaque référence, c'est un singleton. Si l'utilisation compte des retours inattendus à 1 après une période d'augmentation, vous avez un bug. –