Bubbling Events

[=?Utf-8?B?UGF1bA==?=]

Hello,

I am aware that in ASP.NET there is the concept of event bubbling. What I am
after is some advice on achieveing the same thing in a standard application.

Say I have 3 classes. View, Controller and Model.

View calls Controller and then Controller calls Model.

I would like Model to raise events which the View can handle.

What is the best practice way to achieve this? Should i just raise the event
in Model and then re-raise it in the Controller? Or is there a better way?

Thanks
Paul

[Peter Duniho]

On Mon, 22 Sep 2008 12:08:04 -0700, Paul <Pa**@discussio ns.microsoft.co m>
wrote:

I am aware that in ASP.NET there is the concept of event bubbling. What
I am
after is some advice on achieveing the same thing in a standard
application.

Say I have 3 classes. View, Controller and Model.

View calls Controller and then Controller calls Model.

I would like Model to raise events which the View can handle.

What is the best practice way to achieve this? Should i just raise the
event
in Model and then re-raise it in the Controller? Or is there a better
way?

I suppose that depends on your interpretation of the MVC design pattern.

You certainly can use the controller as a proxy as you suggest, forwarding
events from the model to the view. In that design, the view would be
aware of the controller and would subscribe itself to the events in the
controller.

An alternative would be to have the view implement some interface that
includes event handlers, and have the controller simply subscribe those
event handlers to the model's events.

Of course, I'm speaking generalities here. I understand that there's an
actual MVC framework in ASP.NET, and it's possible that there's some sort
of pre-defined convention in that framework you could follow.

I don't know anything about that particular part of .NET though, and this
isn't the best forum for ASP.NET questions (my understanding is that there
is in fact an ASP.NET-specific newsgroup). If you want an answer that is
truly ASP.NET-specific describing how the ASP.NET behavior would be
implemented outside of ASP.NET, you should probably post your question in
the ASP.NET-specific newsgroup.

Pete

[=?Utf-8?B?UGF1bA==?=]

sorry maybe using MVC was a bad example. Lets just say it 3 classes in a
hierarchy. The class at the bottom is the event raiser. The class at the top
must handle the events...but it can only talk to the middle class. And the
middle class can only talk to the bottom class. It's not asp.net.

"Peter Duniho" wrote:

On Mon, 22 Sep 2008 12:08:04 -0700, Paul <Pa**@discussio ns.microsoft.co m>
wrote:

I am aware that in ASP.NET there is the concept of event bubbling. What
I am
after is some advice on achieveing the same thing in a standard
application.

Say I have 3 classes. View, Controller and Model.

View calls Controller and then Controller calls Model.

I would like Model to raise events which the View can handle.

What is the best practice way to achieve this? Should i just raise the
event
in Model and then re-raise it in the Controller? Or is there a better
way?

I suppose that depends on your interpretation of the MVC design pattern.

You certainly can use the controller as a proxy as you suggest, forwarding
events from the model to the view. In that design, the view would be
aware of the controller and would subscribe itself to the events in the
controller.

An alternative would be to have the view implement some interface that
includes event handlers, and have the controller simply subscribe those
event handlers to the model's events.

Of course, I'm speaking generalities here. I understand that there's an
actual MVC framework in ASP.NET, and it's possible that there's some sort
of pre-defined convention in that framework you could follow.

I don't know anything about that particular part of .NET though, and this
isn't the best forum for ASP.NET questions (my understanding is that there
is in fact an ASP.NET-specific newsgroup). If you want an answer that is
truly ASP.NET-specific describing how the ASP.NET behavior would be
implemented outside of ASP.NET, you should probably post your question in
the ASP.NET-specific newsgroup.

Pete

[Peter Duniho]

On Mon, 22 Sep 2008 13:00:14 -0700, Paul <Pa**@discussio ns.microsoft.co m>
wrote:

sorry maybe using MVC was a bad example. Lets just say it 3 classes in a
hierarchy. The class at the bottom is the event raiser. The class at the
top
must handle the events...but it can only talk to the middle class. And
the
middle class can only talk to the bottom class. It's not asp.net.

I don't see how the re-framed question changes my response. My response
was generic in the first place, necessarily ignoring the ASP.NET details
(because I don't know anything about them).

I only mentioned the ASP.NET-specific stuff in case you were looking for
something that specifically follows an ASP.NET model. If you don't care
about that, then hopefully my previous reply is useful as-is.

Pete

[=?Utf-8?B?UGF1bA==?=]

hi

sorry. what im asking is what is the best practice way (if there is one) of
getting the events from the bottom to the top.

As i see it i could...

(1) have events raised at the bottom and handled in the middle and then
re-raised in the middle and handled again at the top. this seems like
duplication of effort and like re-throwing exceptions im not sure if it is
frowned upon or not.

(2) i could pass the event around from the middle to the bottom. again im
not sure if i like the idea of passing events around. im not sure if this has
impacts from a thread safety / overhead standpoint.

"Peter Duniho" wrote:

On Mon, 22 Sep 2008 13:00:14 -0700, Paul <Pa**@discussio ns.microsoft.co m>
wrote:

sorry maybe using MVC was a bad example. Lets just say it 3 classes in a
hierarchy. The class at the bottom is the event raiser. The class at the
top
must handle the events...but it can only talk to the middle class. And
the
middle class can only talk to the bottom class. It's not asp.net.

I don't see how the re-framed question changes my response. My response
was generic in the first place, necessarily ignoring the ASP.NET details
(because I don't know anything about them).

I only mentioned the ASP.NET-specific stuff in case you were looking for
something that specifically follows an ASP.NET model. If you don't care
about that, then hopefully my previous reply is useful as-is.

Pete

[Peter Duniho]

On Mon, 22 Sep 2008 13:30:01 -0700, Paul <Pa**@discussio ns.microsoft.co m>
wrote:

sorry. what im asking is what is the best practice way (if there is one)
of
getting the events from the bottom to the top.

Out of context, it's my opinion that describing a "best practice" isn't
possible. There are surely situations where proxying makes a lot of
sense. That said...

(1) have events raised at the bottom and handled in the middle and then
re-raised in the middle and handled again at the top. this seems like
duplication of effort and like re-throwing exceptions im not sure if it
is
frowned upon or not.

I think if you can avoid this, you should. You won't always be able to,
but you're right that it involves extra overhead.

(2) i could pass the event around from the middle to the bottom. again im
not sure if i like the idea of passing events around. im not sure if
this has
impacts from a thread safety / overhead standpoint.

You can't pass an event. It's not something that is instantiated,
referenced, etc. So obviously this approach is not valid.

A third approach, one I mentioned before, is valid: having the middle
class subscribe a method of the top class to an event of the bottom
class. This would rely on either the top class exposing the handler
publicly, or having the top class provide a delegate instance (perhaps via
a property or method that returns the delegate) that can be attached to
the bottom class's event.

It's not a perfect metaphor, but I think of this third approach as being
more of a "push" approach, and the first approach as being more of a
"pull" approach. That is, in the third approach, the middle class is
pushing events onto the top class. In the first approach, the top class
is pulling events from the middle class.

So, if you have a preference between "push" and "pull", that could help
guide your design decision as well.

You could in fact implement an intermediate design in which the top class
explicitly passed a delegate instance to the middle class, rather than
waiting for the middle class to ask it for one, and then relied on the
middle class to subscribe that delegate instance to the bottom class's
event. In that respect, the top class is doing a bit of pulling by
driving the subscription process, while still allowing the middle class to
do a bit of pushing (by taking care of the subscription to the actual
event).

Pete