Are MVP and AJAX a good match?

Can't seem to get through a conversation these days without talking about the MVP pattern - so here's a boring post about just that.

If you need extensive unit testing coverage, adopting the MVP pattern in your app is probably going to make your life easier. In the specific case of web apps though there are a number of considerations to take into account.

First of all, not everyone seems to be aware that MVP was retired a while ago, and it has been split by the author in two different patterns: Passive View and Supervising Controller. In my experience, when talking about MVP, most people implicitly refer to the Passive View model.

Passive View looks like a pretty good fit for the ASP.NET post-back model, where your presenter triggers updates on the view server-side and everyone can feel comfortable they're following the pattern. This is all good till you start sneaking loads of AJAX calls into your page, resulting in a view that has got now inherent behavior (in this discussion I am considering all the client-side scripting as inherent behavior of the view - which might be a wrong assumption, if so please slap me hard). Still nothing wrong, till the AJAX calls from the view go straight down to the model to fetch data which is used by the view to update itself. Bare in mind that here the problem is not so much the view that updates itself, but the fact that, going straight to the model, the view is no longer passive and the presenter doesn't trigger the update (as we obviously don't have a client-side equivalent).

The considerations above seem to rule out the passive view approach for AJAX intensive apps. In fact, in the Passive View pattern the view is only allowed to talk to the presenter (usually through some messaging mechanism). All this to say that if you're adopting MVP in a web project that requires AJAX calls from the client representation of the view to the service layer (the model), you better specify you're not adopting Passive View, because - at all effects - you're not!

But maybe not all is lost.

If Martin Fowler makes a clear distinction between passive view and selective controller there must be a reason (and a pretty good one for sure). In fact, in a scenario where the view selectively talks to the model and updates itself and "the controller/presenter defers as much as it is reasonable to the view", you're basically adopting the Supervising Controller variation of the MVP pattern (even if you don't know). This scenario is particularly well suited in case of databindings, and even if this is not strictly true in the case of loads of AJAX calls down to the model, I would probably see this AJAX scenario a good fit for this variation of the pattern (compared to passive view).

I find it might be easier for people to get it right if they feel they're closely following the pattern - this is definitely true for me!

So in answer to the title question: Are MVP and AJAX a good match?

I think they might - as long as you're not talking about Passive View!

[Design Patterns] Butchering Design Patterns Part 1 - Open Door Pattern

Hi all,

this is the first post of the Butchering Design Patterns series. What we do here is try to highlight Design Patterns very common between butchers. Just like everyone, they often don't know they're using these patterns, they just go ahead with their unplanned coding and these patterns just emerge. Some of them make sense, some others do not, but after seeing them a number of times you may need to classify them.

Open Door - the Open Door Pattern is not particularly exciting but is very common between coding butchers.

Definition: define an abstract class declaring all your variable members as public, then implement a getter and setter for each of them. Define a concrete child class for your abstract class; when you need to set/get the variable member value, just use the first way that comes to your mind (access directly or through the getter/setter), or toss a coin if in doubt.

Frequency of use: very high

UML Diagram:
















Partecipants:
AbstractOpenDoor: declares an interface common to all concrete open doors.
ConcreteOpenDoor: inherits from abstract open door.

Code Sample:

// Open Door Pattern -- Structural example

using System;

namespace DotNetButchering.ButcheringPatterns.OpenDoor.Structural
{

  // MainApp test application

  class MainApp
  {
    const string scuffia = "Dirty Sanchez Lover";    

    static void Main()
    {
      ConcreteOpenDoor myOpenDoor = new ConcreteOpenDoor(0);
   
      //It's good practice to use getter/setter
      if (myOpenDoor.GetGenericMember() == 0)
        myOpenDoor.SetGenericMember(1);

      //...

      //Now I am in a bit of a rush, I'll access directly
      myOpenDoor.m_genericMember = 2;
   
      //..

      //I am not the butcher who developed this, and I'll probably never notice
      //that m_genericMember is public
      if(scuffia == "Dirty Sanchez Lover")
        myOpenDoor.SetGenericMember(3);
   
      //..

      // Wait for user
      Console.Read();
    }
  }

  // "Abstract Open Door"

  abstract class AbstractOpenDoor
  {
    public T m_genericMember;
 
    public virtual T GetGenericMember()
    {
      return m_genericMember;
    }

    public virtual void SetGenericMember(T genericValue)
    {
      m_genericMember = genericValue;
    }
  }

  //"Concrete Open Door"
  class ConcreteOpenDoor: AbstractOpenDoor
  {
    public ConcreteOpenDoor(T initValue)
    {
      m_genericMember = initValue;
    }

    //whatever
  }

That's all about the open door pattern. Keep in mind it is common to find it used without any abstract base.