Event Bubbling and MVP: ASP.NET

TLDR the code.

Here's how I would do it. You say there are 2 controls on the same page. So that can be served by a ContainerVM with references (members) of TimeVM and MonthVM.

1. TimeVM updates a backing property ResultantDate whenever you do your thing.
2. ContainerVM has subscribed to property-changed notifications for TimeVM.ResultantDate. Whenever it receives a change notification, it calls MonthVM.SetMonth()

This can now be tested without using any views - purely at the presenter level.

Thanks for the inputs. I referred MVP Quickstarts http://msdn.microsoft.com/en-us/library/ff650240.aspx. Model can raise events. I think, I should go with that approach. Any thoughts are welcome.

Also, I have posted http://forums.asp.net/t/1760921.aspx/1?Model+View+Presenter+Guidelines to collect general rules on MVP.

Quote

Develop Presenter which can communicate with both View and Model. Presenter may only have knowledge of view interfaces. Even if the concrete view changes, it does not affect presenter.

In the concrete view, control’s event handlers will simply call presenter methods or raise events to which presenter would have subscribed. There should be no presentation rule/logic written in concrete view.

Presenter should have only interface object of model; not concrete model. This is for the ease of Unit Testing

View can refer business entities. However there should no logic written associated with the entity objects. It may just pass the entity object to presenter.

View interface should be an abstraction. It should NOT have any control or System.Web reference. In concrete view, there should be no method other than interface defined methods.

The "Model" never knows about the concrete view as well as the interface view

"Model" can define and raise events. Presenter can subscribe these events raised by model.

Public methods in presenter should be parameterless. View object should access only parameterless methods of presenter. Another option is view can define events to which the presenter can subscribe. Either way, there should be no parameter passing.

Since the model has all the required values (to be stored back in database), there is no need to pass any value to model from view (most of the time). E.g. when an item is selected in dropdown list only the controls’ current index need to be passed to model. Then model knows how to get the corresponding domain values. In this case, the view need not pass anything to presenter. Presenter knows how to get value from view.

View may make use of model directly (without using presenter). E.g. ObjectDataSource's SelectMethod. But controller never knows about the concrete view as well as the interface view.

The presenter references the view interface instead of the view's concrete implementation. This allows you to replace the actual view with a mock view when running unit tests.