tmlipinski (2) [Avatar] Offline
#1
Hi, Mark,

This is my first post here, so: congratulations and many thanks for your excellent book!

In the section dedicated to WebForms (7.5.1) you've written, that the container instance should be stored in the Application Context. Let's assume that I'm using some kind of MVP pattern. I want to inject views (i.e. aspx pages) into presenters through the Constructor Injection. I do it inside an existing page - there is no other option - and therefore I must declare (to the DI container) this page as the instance of the desired view interface (to be properly resolved while resolving the presenter).

It seems to me that it makes storing the container instance in the Application Context a little bit dangerous. Would it be better to store it in the Session Context (and do it in the Session_Start event in the global.asax)?

Best regards
Tomasz
mark.seemann (383) [Avatar] Offline
#2
Re: WebForms: The container instance in the Application or the Session Context?
Hi Tomasz

Thanks for writing.

Doesn't that design give you a circular dependency?

In any case, isn't it ultimately a question of proper lifetime management? Let's assume that there's a good way of providing the Page instance to the container (that depends a little upon which container you use). If you configure that Page instance as Transient or Per Web Request, various Page instances shouldn't conflict with each other.

However, life cycle management becomes very important because you may have to Release the Page after everything has been resolved. Otherwise, the container may keep all Page instances alive, which is certainly not what you want. However, again, the specifics depend on which container you use.

All in all, that sounds difficult, so wouldn't it just be easier to create a new container instance inside a Page instead? Yes, easier, but then you totally lose the option of reusing shared thread-safe (Singleton) services across requests.

Then what about storing the container in a session? You still lose the ability to use shared (Singleton) services. Also, keeping state in session is rarely a good idea. The book "Release It" explains how it can have a severe impact on the capacity of your system. Also, if you want to be able to run in a web farm with non-sticky sessions, you must be able to serialize all session state. Do you really want to serialize container state across the network? That sounds like a road filled with pain...

HTH

Mark Seemann
tmlipinski (2) [Avatar] Offline
#3
Re: WebForms: The container instance in the Application or the Session Context?
Hi, Mark,

Yes, this design gives me a circular dependency. But it seems to be difficult to give it away in the MVP pattern?

You are right, I just have not to be lazy and to clean up after myself smilie.

And the last thing - check, please, whether I'm right:
- the application state is kept "InProc" and therefore I can keep there everything (i.e. even not serializable items)
- the application state is not shared between servers in a web farm; the Application_Start event is raised at every server in the farm
- this could be important for singleton lifetime objects only; but since such objects should be stateless - it doesn't matter
And as a conclusion: that is why keeping the DI container in the application state works well in every situation.

Thanks for all explanations.
Best regards
Tomasz
mark.seemann (383) [Avatar] Offline
#4
Re: WebForms: The container instance in the Application or the Session Context?
Yes, that is correct.