Store presenters

Hello,

I think I know the answer to my question, but I just want to be sure... My web
application is developed using a variation of MVP pattern. So I have passive
views (which are my ASPX-pages) and for each one of them I have a presenter
class. Now, each view creates the corresponding presenter and passes it a
reference to itself:

class SomePage : Page
{
   public SomePage
   {
       SomePagePresenter presenter = new SomePagePresenter(this);
   }
} 

 Now, the question is where should I store all these presenters. I could store
them inside the page class, but I don't like this idea, because my page doesn't
need to have a reference to its presenter! Once it creates it, the presenter is
responsible to register to all page's events that it is interested in, and then
the page itself is only responsible to fire these events. So the page never
calls any presenter's methods. Therefore there is no reason to store the
presenter inside the view. 

Actually, NO ONE calls the presenter's methods! The presenter is an observer
which only registers itself to other's events. So it just should *exist*, no one
will ever  ask a reference to it. Therefore I've decided to store all the
presenters inside the Session hash. So is this a good idea? As far as I know,
the Session hash is stored on the server side, and the client only passes the
session identifier with each its request. Am I right? Perhaps you can offer a
better idea?

Thank you.

Where/if the presenter is stored is not a cause for concern. Storage doesn't
cause dependencies, instantiation does.  It's fine that your page/view doesn't
need the reference, i.e don't store in anywhere.

If you need a reference somewhere Session is not a good choice, since it makes
the application dependent on that you're using in-proc Session mode, and a
presenter's scope is  just one request (just as the Page/View), not an entire
Session.

"Dmitry Perets" wrote in message news:2246914@forums.asp.net...

Hello,

I think I know the answer to my question, but I just want to be sure... My web
application is developed using a variation of MVP pattern. So I have passive
views (which are my ASPX-pages) and for each one of them I have a presenter
class. Now, each view creates the corresponding presenter and passes it a
reference to itself:

class SomePage : Page
{
   public SomePage
   {
       SomePagePresenter presenter = new SomePagePresenter(this);
   }
} 

 Now, the question is where should I store all these presenters. I could store
them inside the page class, but I don't like this idea, because my page doesn't
need to have a reference to its presenter! Once it creates it, the presenter is
responsible to register to all page's events that it is interested in, and then
the page itself is only responsible to fire these events. So the page never
calls any presenter's methods. Therefore there is no reason to store the
presenter inside the view. 

Actually, NO ONE calls the presenter's methods! The presenter is an observer
which only registers itself to other's events. So it just should *exist*, no one
will ever  ask a reference to it. Therefore I've decided to store all the
presenters inside the Session hash. So is this a good idea? As far as I know,
the Session hash is stored on the server side, and the client only passes the
session identifier with each its request. Am I right? Perhaps you can offer a
better idea?

Thank you.
http://forums.asp.net/p/1236676/2246914.aspx#2246914


There's no reason to store a reference to the Presenter, if the Presenter is
never called *and* the Presenter attaches itself to the Page events. If you
think about how events work, you'll see the reason why....the event raiser (your
Page) holds a reference to the event handler (your Presenter), which keeps the
handler alive until the raiser is GCed (or the handler is removed). Note that
the handler (Presenter) does not keep the raiser (Page) from being GCed. As an
aside, it's a common source of "memory leaks" in Windows Forms -
attaching but never removing handlers to long living objects. --MB