Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm trying to figure out how MVP should be implemented at the UserControl level. I thought I had it, but I ended up reading a blog post that pretty much shut me down. Now I'm back at the start and with no idea how to proceed.

Let's say my UserControl is something simple like two TextBoxes and a ComboBox. This gets invoked from a main form (which has its own View and Presenter). Now, the way I understand MVP is that the Main Form Presenter is supposed to invoke a second presenter to handle all communication with the UserControl that gets dropped there.

And this is where I get completely lost. My past implementations of UserControls (before I learned MVP) always incorporated the logic behind the control (e.g. ComboBox selection will change text label related to TextBox1). As such, implementation of the UserControl is done by dragging it onto the designer, and then calling commands like UserControl1.Update() or UserControl1.DisplayData(data).

In any third-party UserControl, all commands to the UserControl are performed by commands to the control. There is no "presenter" that needs to be invoked, for instance, when I drop a ComboBox, or a ListView, or any other WinForms control onto my form. Yet they have internal logic that dictates how they display, and in the essence of testing, it should have a "presenter" separation to it somewhere.

I thought that a good solution would be that the constructor of my UserControl would create a Presenter. Any commands to the UserControl would delegate straight to the Presenter. This would allow my UserControl to have its own presentation logic separated from its "view", such that I can test it, and such that the implementer (the Main Form) need only drop in the UserControl and perform data sends and receives as part of its local presentation logic. The UserControl has its own presentation logic left invisible to the implementer.

And just when I thought I understood it all, I find out that it's bad practice (The Self-Aware View). So I plead with people who understand this better than I: How do I construct a UserControl that keeps its presentation logic invisible to the end-user, such that I don't have to construct the wrapping presenter in my Main Form, without violating the principles that Matt Wynne discusses in the linked post above?

Or am I completely misunderstanding the concept of MVP here?

share|improve this question
add comment

2 Answers 2

I read through Matt Wynne's blog entry that you linked, and I can see where some of the confusion is coming from. So let's point out a few differences between his article and your situation.

  • Your question was asked on Aug 21st of 2013. Matt's article was published on June 13 of 2007.

  • You tagged your question with and , although I think you meant instead of winForms. Matt states his focus and experience has been with ASP.NET.

I want to point out that we're already at a) dated advice and b) differing UI technologies.

ASP.NET and the MV* pattern(s) it supports have changed significantly since then. Likewise, users of Silverlight and WPF have since generated a lot of guidance with using the MVVM pattern and data binding.

And as a point of reference, I would recommend reading over Martin Fowler's articles on Passive View and Supervising Controller which are the patterns he broke out from his original MVP pattern.


I think your question is more interesting when looking at the broader point of view and asking "what does MV* help me with for a framework?" And the primary driver of this family of patterns is to encapsulate the areas that are likely to change. Related to that encapsulation is the single responsibility principle and making sure each component owns what it should.

We encapsulate all of the view logic in the View layer so we can more easily change out our UI technology at an appropriate point later on in time. Likewise with the Model and whatever you choose to use with the middle layer.

So the answer to your question is to put the appropriate view logic within that layer to make your technology work. If you're using winForms, you'll end up with a lot of code-behind in order to make the form work. WPF supports data binding and significantly reduces the amount of code-behind. The logic you put in the View should potentially go away when you change UI technologies.

Likewise, if you have presentation rules that are not imposed by the UI technology then you'll put those rules in your middle layer as they need to persist into your next UI.

I don't mean to diminish the fact that there are differences between the MV* patterns, and those differences exist for good reason. But their development was driven by the needs of particular technologies. You're using potentially different tech, so use the MV* pattern appropriate for your environment. The frameworks are there to facilitate future change, not handcuff your current development.

share|improve this answer
    
A) I'm coming to realize that one should take advice with a grain of salt, though it's particularly unusual for me (my background is engineering, so things that are decades old are still relevant) where in software, something a few years old may no longer be relevant. The world changes fast here. B) I did not mean WPF. I have little experience with WPF, though I am familiar with the mechanic of MVVM due to the background reading I've done on MV*. I do enjoy the differences between WinForms and WPF, but I have not yet decided when I'll start migrating to WPF with new development projects. –  Arclight Aug 25 '13 at 12:53
    
You also mention that we break out our UI into an MV* pattern so we can change the UI in the future. I think the disconnect I've been having is that I don't see WinForms changing often, where on the contrary I can see webpages through ASP.NET changing fairly frequently. At the same time, I can understand the need to separate the layers for any potential changes in the future, but I felt that the focus of my usage of these patterns was such that I could unit test my code. (My thought process getting to this point was: "You can unit test code" -> "How do I unit test a UI?" -> "MV*") –  Arclight Aug 25 '13 at 12:58
    
@Arclight - speaking as a fellow engineer, I fully agree that software is a different beast than the other fields of engineering. You should be comfortable with applying a healthy dose of skepticism to any advice that's given until you understand the principles it is trying to advocate. One major difference with WPF and the MV* patterns is the ability to bind elements within the view to the elements in the view model layer. Binding gets rid of so much overhead code that you have to experience it to believe it ... –  GlenH7 Aug 25 '13 at 18:17
    
@Arclight ... And there's a nuance with the encapsulation that I don't think you quite caught. The UI technology itself won't change - ie. winForms is "dead" and won't see anything new. What changes is what technology you're going to use next in that application. By having all of the UI technology specific dependencies within the View layer, it becomes that much easier to A) switch to a new technology (like WPF) and B) not re-write business logic that will persist well beyond a particular UI technology. –  GlenH7 Aug 25 '13 at 18:19
add comment

That blog post is just my experience - you should try this stuff for yourself and don't let my ranty blog post knock your confidence!

Try reading this: http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf And this: http://atomicobject.com/files/PresenterFirstAgile2006.pdf

Those were very influential for me when I developed my understanding of MVP.

Good luck.

share|improve this answer
    
would you mind expanding a bit on what each of these resources have and why do you recommend these as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange –  gnat Aug 21 '13 at 21:20
    
While I've been familiar with The Humble Dialog Box (that's actually what got me into figuring out MVP in the first place), I have never seen that paper on Presenter First before. That is amazing. My recent development has struggled from trying to figure out what to build first; in the past, I always made the form first, but recently, I've been making the model first, and it starts to bloat (I suffer from "Hey, it might need this later!" syndrome). Presenter First makes a lot of sense. Thank you for posting that. –  Arclight Aug 25 '13 at 13:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.