Event Bubbling and Mvp: ASP.NET

Event Bubbling and MVP: ASP.NET

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.

Why do Presenters attach to View events instead of View calling Presenter Methods in most ASP.NET MVP implementations?

Sure they can, and I find that to be the best middle ground. What you are describing is I believe called Observing Presenter style. This allows you to completely decouple View from the Presenter, making the view less susceptible to changes within presenter. But it also introduces complexity in testing, and that is the reason to use MVP to begin with. I would not bother with this style at all. On very large project we use Encapsulated Presenter style, where View has a reference to Presenter, injected via IoC container, and view just calls methods on the Presenter. Easy to understand, easy to debug, easy to test.

MVP - Should views be able to call presenter methods directly or should they always raise events?

I use direct method calls, and don't see any worhtwhile reason to be defining events on the presenter. What you are using with events is called I believe "Observing Presenter" style. It does offer complete decoupling of View from Presenter, but with added complexity.

Restrict violation of architecture - asp.net MVP

I'm afraid this is not possible. We tried to achieve this with the help of attributes and we didn't succeed. You may want to refer to my past post on SO.

The best you can do is keep checking your assemblies with NDepend. NDepend shows you dependancy diagram of assemblies in your project and you can immediately track the violations and take actions reactively.

_{(source: ndepend.com)}

Event handling across views/forms (MVP-VM framework)

Enclosing the comments into the answer:

What's needed here is the Event Aggregator pattern.

As you suggested, the simple messenger implementation should work quite nice, if you want to roll out your own, you can always peek into the Caliburn.Micro implementation or Mvvm Light Messenger in the MVVM Light Toolkit for inspiration.

MVP on Asp.Net WebForms

Your controller should be in charge of setting the "result" of the databinding. The view is in charge of displaying it propertly.

So for example, your webform/usercontrol (View) could have the data source exposed as an object property that your View should know how to handle when it receives it:

public MyObject DataSource 
{
  set 
  { 
    _datasource = value; 
    _datasource.DataBind(); 
  } 
}

So if you need to have an ItemDataBound event, I would still handle it in the view. Even though there could be business logic in the event. If you need to have business logic in the event, I would put it in the MyObject result before it is passed to the view.

So an example would be to have a property of "MyObject" be "AllowDelete" and in your ItemDataBound, the value of this property determines if a column in the GridView is enabled or not.

---

Related Topics