I had recently been reading about the Model View Presenter design pattern and although I found it interesting, it didn’t quite fit the bill for my current client.
One of the main facets of the pattern is that it ensures the UI code is testable, especially in unit tests, but if you are not implementing full test-driven development the pattern seems like it could simply be an unnecessary layer.
Or so I thought until this week.
A situation presented itself this week that made me think that adapting the view model may be very beneficial for us.
We have two custom controls on a web page – one is a news article control that delivers news, picture, by lines (etc) and the other is a social bookmark control. Both are independent of each other so the bookmark control needs to have properties set from information in the article.
This is currently achieved by the page providing a delegate to the article control – when the article data is retrieved and the control populated, the event is raised to advise of the title (and other properties).
The page code behind then sets the bookmark control’s properties and fires a custom creation method for that control.
It all works great and we haven’t had any problems so far.
What suddenly clicked with me this week though is that there was something not right about the property assignment process… the code was fine and is illustrated below, but somehow something was up!
bookmarks.BookmarkTitle = title;
bookmarks.BookmarkUri = new System.Uri(url);
bookmarks.BookmarkGeneratorID = articleID;
bookmarks.BookmarkGeneratorType = GeneratorType.Article;
bookmarks.CreateCustom();
Again, the problem we have is not with the code itself, but with the enforcing of its implementation.
All of these properties have to be set in the bookmark control for it to be valid – an application exception is raised if they are missing or incorrect and again this is fine.
However, if I or another developer goes to implement the bookmark control in another of our websites the only way we know if all the properties are being set as they should be is that a run-time exception will be generated during testing.
Hmmm. This seems very loose – how can we enforce the assignment of these properties through design so that at compile-time we can see the error of our ways?
(note: this control must be declared in the aspx page, so we cannot create a new constructor, the default one is used by .NET in the HttpHandler when it creates the controls.)
Well, we could provide just the one method on the bookmark control that assigns the properties, but this doesn’t seem right either.
This is when I thought back to the model view presenter – if we can define a viewer interface we can force the page (viewer) to implement certain contracted properties and methods and this ensures that each is actioned and implemented.
Of course this can’t stop foolish implementation such as simple”return true;” code in the methods but it does force the developer to do something.
Here is a quick example I’ve rumbled up for this post:
public interface IBookmarkViewer
{
string BookmarkTitle { get; }
System.Uri BookmarkUri { get; }
int BookmarkGeneratorID { get; }
GeneratorType BookmarkGeneratorType { get; }
}
Here we are forcing the viewer to implement these properties and here is an example of what the page might be like in action as a “viewer”:
public class articlepage: BiscuitBasePageClass, IBookmarkViewer
{
public string BookmarkTitle {
get { return _title; }
}
public System.Uri BookmarkUri {
get { return _uri; }
…
etc
The rest of the implementation can be derived from the actual model view presenter pattern – here I am simply sounding out an idea in the post and have not written or tried to implement this.
Has anyone else implemented something similar, like a “slim” version of that pattern as illustrated above?
Note: the author of the pattern, Martin Fowler, has changed the original pattern and split it into two distinct ones- you can view his description of that here.
