Tying MVP To the ASP.NET Event Model

0 comments suggest edit

I knew this question would come up, so I figure I would address it in its own blog post. Mike asks a great question about my MVP implementation (actually he asks two).

One observation…don’t you seem to be tying the presenter to the ASP.NET event model? If not, can you use the same presenter for a WinForms app?

The answer is that I am absolutely tying my presenter to ASP.NET.

Why?

Well when I first working on the article, I planned on creating an abstracted IView and presenter that would work for both ASP.NET and Windows Forms, but ran into a few problems. The biggest problem is that I rarely have to write a Windows Forms applications. In fact, I almost never do. So why spend all this time on something I won’t need? I had to call YAGNI on my efforts.

Premature Generalization

Besides, I didn’t want to run afoul of Eric Gunnerson’s #1 deadly sin of programming, premature generalization. There is no point in writing an IView and Presenter to work with both winforms and ASP.NET unless I am also implementing concrete instances of both at the same time. Otherwise I will write it for one platform and hope it will work for the other. If I ever do implement it for the other, I will probably have to rewrite it anyways.

Parity is a rarity

Secondly, even if I did need it, there are some other issues to deal with. First, trying to write a single presenter for both ASP.NET and a WinForms app assumes the user interaction with the application and the view is going to be roughly the same. That is rarely the case. If I have to go to the trouble to write a Winforms app, I will certainly take advantage of its UI benefits.

Leaky Abstractions Rear Their Head

Thirdly, despite all the hoops that ASP.NET jumps through to abstract the fact that it is a web application and present an API that feels like a desktop platform, it is still a web application platform. The abstraction is leaky and trying to abstract it even more causes problems.

For example, in a Winforms view, you only need to call the Initialize method once because the data is persistent in memory. With an ASP.NET view by default, you have to essentially repopulate every data field every time a user clicks a button. Can you imagine a Winforms app written like that?

Of course you could more closely simulate the Winforms view in ASP.NET view by storing these fields in ViewState or, shudder, Session, but this then becomes a constraint on your ASP.NET view in order to support this pattern, forcing you to take a Winforms approach to a web based app. Ideally a presenter for an ASP.NET application should not have to assume that the ASP.NET view is going to store fields in a persistent manner.

Conclusion

So that is a long-winded answer to a short question. I believe if I had to, I could get the same Presenter to work for both a Winforms App and an ASP.NET app. These problems I mention are not insurmountable. However, I would need to be properly motivated to do so, i.e., have a real hard requirement to do so.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.

Comments

avatar

7 responses

  1. Avatar for Billy
    Billy August 9th, 2006

    "Premature Generalization" - I love it! Up front planning certainly has its place, but it drives me nuts when I hear developers boasting that 80% of their code has been put into a reusable, configurable framework for everyone else to use. Because A) YAGNI, B) only 10%, if any, is ever going to be reused and C) they just blew their schedule and budget building something that brought no value to the client.

  2. Avatar for Thomas Eyde
    Thomas Eyde August 9th, 2006

    Remember the User Interface Process Application Block, or UIP for short?
    One of its missions was to enable us to write the same workflow code for both worlds. I can't say how it works for WinForms, but I had to abandone it for WebForms.
    I hadn't used it for long before I ran into some severe bugs which clearly revealed poor or no testing, like a session lost due to timeout or a recompile. Also hitting the back button moved the UI into an invalid workflow state which was impossible to escape from.

  3. Avatar for Mike
    Mike August 9th, 2006

    he he...Glad I inspired a post :)
    I understand the generalization principle (and like it!)...I was originally constructing the project I am working on right now for ASP.NET exclusively and have begun to see the need to allow some stuff squirt onto a PDA (of which i have NO experience), so it's a consideration for me.
    I started with the UIP (like Gravatar) and also found the overgeneralization to be way to complex.
    I love the MVP pattern and am glad it is getting so much press. Thanks for your writeups!

  4. Avatar for Travis James
    Travis James August 9th, 2006

    I completely concur on this point. I spent a lot of time in my own application framework crafting a set of interfaces and presentation services that actually was a consistent programming model for both platforms, including support for a Command pattern implementation used to abstract the event handling differences between WinForms and WebForms apps (the controller was responsible for providing a "Command" factory which was used to create "Command" objects in the "IView" abstract base implementation.
    Over the development cycles of several systems, I only found the common abstractions useful one time across web and Windows implementations (where web services and domain objects were involved). Even in that case, the Command pattern abstraction was only useful in the Windows implementation.
    In practice, it turns out that the MVP abstractions for web and Windows applications are only common at the very highest levels, and there is not much to be gained by attempting to make the two share any significant parts of an implementation framework. YAGNI.

  5. Avatar for Brian
    Brian August 10th, 2006

    You cite YAGNI as a reason for not creating it so that the View can be used in both ASP/Win Forms, if that is the case then why go through the process of creating a view at all? Just by creating a View aren't you making a 'premature generalization'?

  6. Avatar for Haacked
    Haacked August 10th, 2006

    Brian, not at all. I use the view in two places. In the actual ASP.NET page and in my unit tests. The view increases the testability of the code.

  7. Avatar for Bruce
    Bruce December 19th, 2006

    Hmm, well that just stuff's up my hopes for Xaml :)