Structuremap Scope/Lifecycle Guidance?

Question

Is there any reason to switch from the default scope (transient?) to something else, outside of needing to control the scope for functional reasons (e.g. Singleton)?

If I stick with the default scope, every default instance of every plugin type will effectively get instantiated on each request (assuming a web app), is that correct? Can this affect performance noticeably?

I've considered using Http Session scope to limit this to one instance per user logged in. However, that will result in (at least) one instance of each plugin type stored in memory for each user at all times. Using default scope, these instances would only be held in memory while a page request was being processed. I'm not sure which is preferable.

If you use StructureMap, how do you generally configure scope for each of your plugin types?

Thanks for any insight,

Phil

Answer 1

I leave the default scope in place. This means that per every one request (either by each user or by many users) I have an instance of an object in hand. This means that a new request is made each time. Keeping it in session is something that I prefer to have more specific control over. For this reason I may throw a caching layer over the service layer and stick StructureMap returned object into. I can then query the cache for already instantiated (now serialized) object and choose where to get my objects from.

I would do the same thing for a Singleton configuration where I would use StructureMap to get the actual object...but when it goes to return the object a 2nd time, the object itself would hand off an instance to itself (in singleton terms that is). This uses StructureMap for it's power...but doesn't give it more power than is needed.