MVP implementation

Topics: Web Client Software Factory, User Forum
Oct 12, 2007 at 7:16 PM
First, let me say I really love the work that you guys are doing. And now that the love fest is over, I thought I would share a couple of my frustrations which are both related to MVP.

Why are views associated with presenters via a property (i.e. _presenter.View = defaultView) instead of via a paramter in the constructor (i.e. _presenter = new DefaultPresenter(defailtView))? Not only does this have a bit of code smell to it (since you have to remember to set the property before you can use the presenter), but it's also not the "official" protocol for MVP (e.g. http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx).

I would also suggest changing the way the MVP artifacts are organized. Specifically, I've found that combining the view interfaces and presenters together in the same namespace can become overwhelming after a while. In the past, I have used a pattern like:

  • Root Namespace
    • ModuleFoo
      • Presentation
        • Presenters
        • Views

Along the same lines, I think it's also confusing to try and place the supporting classes for the aspx pages in the same namespace as their respective presenters. Personally, I find this confusing since it creates a namespace that spans assemblies. I think it makes more sense to just let it be what it wants to be: <Project Root Namespace>.<Folder Name>

Just my 2 cents.
Oct 12, 2007 at 9:48 PM
Hi.,

Regarding your first question, if you used new DefaultPresenter(defailtView), you would have to also provide all the other dependencies that the presenter needs (in every view). This would probably increase the code duplication in your views. To avoid this, we preferred to use the CreateNew attribute. Since ObjectBuilder cannot inject the view in the presenter (because the view is not created by ObjectBuilder, but by the ASP.NET engine), we need to manually set the View property of the presenter.

Regarding your second point, I should say that the MVP pattern can be implemented in many different valid ways. If you are willing to do this, you can modify the guidance package to suit your needs.

Please let me know if this helps!

Ignacio Baumann Fonay
http://staff.southworks.net/blogs/ibaumann/
Oct 17, 2007 at 2:50 PM
We've handled DI in our MVP implementations through simple constructor overloading.

e.g.
public DefaultView(IDefailtView view) : this(view, new DefaultController()) {}
public DefaultView(IDefailtView view, IDefaultController controller) {}

Views call the first constructor, while tests call the second. The controller constructor could be similarly overloaded to facilitate DI for the service types.

Forgive me, since I'm new to ObjectBuilder, but what are its advantages over this approach (other than needing only one constructor)?
Oct 19, 2007 at 1:53 PM

And I wasn't suggesting that Object Builder is somehow inferior or needs to be replaced. I know the team put a vast amount of time into designing the architecture, and I'm just trying to tap into that thought process. OB obviously provides some value to WCSF since it was chosen over the traditional implementation of MVP. I was just wondering what that value is.