Structuremap Scope/Lifecycle Guidance?

Question

Y a-t-il une raison de passer de l'étendue par défaut (transitoire?) À autre chose, sans avoir besoin de contrôler l'étendue pour des raisons fonctionnelles (par exemple, Singleton)? Si je m'en tiens à la portée par défaut, chaque instance par défaut de chaque type de plugin sera effectivement instanciée sur chaque requête (en supposant une application web), est-ce correct? Cela peut-il affecter sensiblement les performances? J'ai envisagé d'utiliser la portée Http Session pour limiter cette instance à une instance par utilisateur connecté. Cependant, cela entraînera (au moins) une instance de chaque type de plugin stockée en mémoire pour chaque utilisateur à tout moment. En utilisant l'étendue par défaut, ces instances ne seraient conservées en mémoire que lorsqu'une demande de page était en cours de traitement. Je ne suis pas sûr de ce qui est préférable.

Si vous utilisez StructureMap, comment configurez-vous généralement la portée pour chacun de vos types de plugins?

Merci pour toute idée,

Phil

Answer 1

Je laisse le champ par défaut en place. Cela signifie que pour chaque requête (soit par chaque utilisateur ou par de nombreux utilisateurs) j'ai une instance d'un objet en main. Cela signifie qu'une nouvelle requête est faite à chaque fois. Le garder en session est quelque chose que je préfère avoir un contrôle plus spécifique. Pour cette raison, je peux lancer une couche de cache sur la couche de service et coller l'objet StructureMap retourné dans. Je peux alors interroger le cache pour un objet déjà instancié (maintenant sérialisé) et choisir l'endroit d'où mes objets doivent provenir. Je ferais la même chose pour une configuration de Singleton où j'utiliserais StructureMap pour obtenir l'objet réel ... mais quand il retournerait l'objet une seconde fois, l'objet lui-même lui remettrait une instance (en termes singleton qui est). Cela utilise StructureMap pour sa puissance ... mais ne lui donne pas plus de puissance que nécessaire.