Home > Design Patterns, Programming > Model View Presenter tips.

Model View Presenter tips.

There are some excellent articles on the Model View Presenter pattern –

A Simple Example of the “Humble Dialog Box”

More Thoughts on Model View Presenter

Model View Presenter with ASP.NET

However, the question that I was struggling most with, was – what properties or methods should be exposed by the View interface? Here are a few tips that I’ve learned so far (and which have been taken from some of the articles mentioned above) –

Have the Presenter class and the View interface in the same (C# ) assembly. Since the assembly that has the actual view, needs to have a reference to the assembly containing the View interface, the assembly with the Presenter does not need to have a reference to the assembly containing the actual View. This way, there are no circular references and the Presenter can easily have a reference to the View interface.

As is obvious, the Presenter class should not have any reference to any UI specific namespaces e.g. System.Windows.Forms namespace or any others.

Most of the times, the View needs to show some drop-downs etc. Hence, the IView interface should have a bunch of property setters so that the Presenter will be able to set this data in the View. Now, why the properties should be just setters and not getter-setters, please refer the Model View Presenter with ASP.NET above.

The View also needs some methods where it’ll initialize some of its controls. e.g. if the View has a TreeView control, it is most likely that the TreeView will be initialized properly (by adding some columns, applying proper editors to those columns etc.) in some method. Now such methods are a good candidate to be a part of the IView interface.

Then, there should be some methods for updating the view, after the user takes various actions on the View. e.g. if the View has a TreeView, then we could have methods like ModifyTree or RefreshTree etc.

Ideally, what methods or properties should come in the IView interface, should be something, which one should decide by tackling the problem in a pure TDD fashion; i.e. write the Unit Tests (for the UI or the View first), which will lead you to these methods or properties.

However, these above tips could come handy for those who are just starting down the MVP path 🙂 and the first question that stares you in your face is – what about IView?

For those, who seriously want to use MVP in their projects, Jeremy Miller has a great series on Build your own CAB which not only has a discussion (and examples) on various flavors of MVP but a lot of other good stuff too, so go check it out.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: