Download the Code Sample
Of all the successful projectsI’ve been a part of, the most successful ones shared a common result: As the application grew larger, the codebase became smaller. On the surface, this may seem contradictory, but coding in an Agile environment lends itself to a shrinking codebase. As requirements change, refactoring occurs, and this refactoring opportunity—coupled with hindsight—provides the ability to reuse existing components more efficiently while eliminating duplicate code in the process.
In contrast, there have been some monolithic projects, which were sometimes deemed successful, where the source code grew and grew with little opportunity for reuse. These projects became resource-intensive and a risk to future growth. What was the fundamental difference? The infrastructural design pattern used. The patterns you use will determine whether you paint yourself into a corner or keep your back to the open opportunities the future might bring.
In this article, I’ll present one such pattern—overlooked by many Windows Presentation Foundation (WPF) developers because of the popularity of the Model-View-ViewModel (MVVM) pattern—called the Model-View-Presenter-ViewModel (MVPVM) pattern. This enterprise application design pattern was introduced in the Microsoft patterns & practices Prism project (Prism.CodePlex.com). (Note: This pattern was unnamed, so I refer to it as MVPVM.) Prism is best described with an excerpt from its Web site overview:
“Prism provides guidance designed to help you more easily design and build rich, flexible, and easy-to-maintain Windows Presentation Foundation (WPF) desktop applications, Silverlight Rich Internet Applications (RIAs), and Windows Phone 7 applications. Using design patterns that embody important architectural design principles, such as separation of concerns and loose coupling, Prism helps you to design and build applications using loosely coupled components that can evolve independently but that can be easily and seamlessly integrated into the overall application. These types of applications are known as composite applications.”
The popularity and success of MVVM overshadows MVPVM even though MVPVM is the evolution of MVVM (as this article will demonstrate). MVPVM provides all of the power and capability of MVVM while introducing the scalability and extensibility of the Model-View-Presenter (MVP) pattern. If your understanding is that MVVM has evolved from MVP for WPF, then you’ll find this article enlightening.
Before we can fully appreciate the power and benefits of MVPVM, we have to understand how this pattern evolved—we have to understand our history. The Model-View-Controller (MVC) pattern is a crucial component to achieving this understanding, so I’ll first introduce MVC, perhaps in a way you’ve never seen before.
Please note that this MVC discussion is within the context of desktop applications; Web applications are another story and beyond the scope of this article.
In Martin Fowler’s “GUI Architectures” document (bit.ly/11OH7Y), he states the following about MVC: “Different people reading about MVC in different places take different ideas from it and describe these as ‘MVC.’ If this doesn’t cause enough confusion, you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers.” The “Whatsa Controller Anyway” document at bit.ly/7ajVeS sums up his point nicely stating: “Computer scientists in general have an annoying tendency to overload terms. That is to say, they tend to assign more than one meaning (sometimes contradictory) to the same word.”
Smalltalk MVC gets further complicated by the fact that developers lack a common core of experience with their great architects in regard to the architect environment. As such, the overloading of terms and “Chinese whispers” are convoluted even more by the fact that most of us don’t even know what a Controller is because we’ve never had to use one—the OS has always handled its functionality for us. With a few facts to provide the common core of experience we lack, you’ll find MVC is actually easy to understand, and that the “C” in MVC has nothing in common with the “P” in MVP.
The Controller does have a concrete origin (which is well worth understanding but doesn’t necessarily match modern approaches to MVC in the context of current technologies). The founding father of MVC, Trygve Reenskaug, wrote about that in 1979 in his document on “Models-Views-Controllers” (bit.ly/2cdqiu). This document begins to provide some insight on the purpose of the Controller. Reenskaug wrote:
“A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and passes these messages on to one or more of the views.
A controller should never supplement the views, it should for example never connect the views of nodes by drawing arrows between them.
Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views, which exactly reproduce any sequence of user commands.”
This concept is illustrated in Figure 1.
A “message,” in the context of MVC object-oriented programming (OOP), is a means of executing methods. They were described as “messages” because back then, virtual calls were a new concept and it was a way of distinguishing them from static function calls. In Chapter 1.2 of the book “Smalltalk, an Introduction to Application Development Using VisualWorks” (Prentice Hall, 1995), by Trevor Hopkins and Bernard Horan, the authors note “… if the receiving object understands the message it has been sent, then one of its internal operations (or methods) will be performed. This, in turn, may cause some computation to take place (by acting on one or more of the object’s internal variables).” (Note: This “message-sending” OOP concept is available in Prism via its EventAggregator.)
The book nicely outlines the responsibilities of Smalltalk MVC in Chapter 29, “Introduction to Models, Views and Controllers,” by teaching us that Controllers derive from the Controller class. It states, “Instances of this class have a reference to a sensor representing the mouse and keyboard, so that it can process input.” It continues to tell us that the two distinct actions initiated from a Controller are communications with the Model (see Figure 1) and communications with the View without affecting the Model.
Figure 1 Controller Receives Input and Sends Message (Method to Execute); Views Can’t Catch User Input
In Smalltalk MVC, “every” View will have a Controller and only one Controller at any given time can be active. In the original Smalltalk MVC, the UI was polled; the top-level ControlManager class asks each of the Controllers of the active View if it wants control. Only the View that contains the cursor can accept control. If a View is read-only, there’s a NoController class available that’s designed to refuse control. A View with subviews has the responsibility to poll the Controllers of its subviews. Once a Controller has accepted control, it will query the results of the keyboard or mouse and send messages to the View or Model as applicable, such as mouse move, button click and so on. In MVVM terms, this would be comparable to subscribing to a control’s events in either the View’s codebehind or via a ViewModel command. When a user interacts with the control, the applicable method will be called.
By this point, you can start to get a glimpse behind the purpose of the Controller within the context of MVC and an environment that doesn’t automatically handle events for you. Unlike Smalltalk MVC developers, WPF developers don’t have to query keyboard buffers and package and raise events. You merely subscribe to them and the applicable method “automagically” receives them via the Microsoft Event Pattern. With this knowledge, the following will perhaps have a different, and less confusing, meaning.
In Steve Burbeck’s article, “Applications Programming in Smalltalk-80: How to Use Model-View-Controller (MVC)” (bit.ly/3ZfFCX), he states the following:
“The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).”
See Figure 2 for an illustration of this concept.
Figure 2 Smalltalk Model-View-Controller
A final point to bring clarity to what could be a muddy topic is in the document, “Twisting the Triad, the Evolution of the Dolphin Smalltalk MVP Application Framework,” by Andy Bower and Blair McGlashan at bit.ly/o8tDTQ (PDF download). This is one of the more comprehensive documents I’ve read on the topic. The authors note the following about the Controller: “The views, of course, are responsible for displaying the domain data while the controllers handle the raw user gestures that will eventually perform actions on this data.”
I bring this final point up so that I have an opportunity to provide another definition. To fully comprehend the article (and others on MVC), you have to understand what “gestures” means (see Figure 1). In my research, I came across the article, “An Introduction to GUI Programming with UIL and Motif” (bit.ly/pkzmgc), which states the following:
“The essence of these steps is that a Motif program does nothing until the user requests some action. The actions are requested by selecting a menu item, by clicking a button or other window, or by pressing a key. These, collectively, are user gestures. Each gesture will trigger an application function to carry out some tasks.”
Andy Bower, coauthor of “Twisting the Triad,” shared his thoughts on “gestures” with me:
“My take on ‘gestures’ is that they’re a coalescence of one or more user events into something more meaningful.
For example a TextController might absorb key down and key up events and convert them into individual ‘keypress’ gestures. Similarly, a SelectionInListController (the Controller attached to a list box) might absorb several mouse-down, mouse-tracking and mouse-up events within a list and treat them as a single list ‘selection’ gesture.
Looked at like this, we see that a modern event-driven OS already does most of this gesture processing for us.”
To summarize Controller logic, you can see that the Controller function is rather consistent among the variations of MVC referenced. Because Microsoft controls (widgets) handle “the mouse and keyboard inputs from the user,” you merely subscribe to the events and point to the method that needs to be executed—the “Controller” within your smart controls executes the method for you (handled at the OS level). As such, you don’t have a need for a Controller, as clearly indicated by the “Twisting the Triad” article. Without the Controller, you’re left with the Model-View pattern for Windows applications. You have to bear this in mind as you study MVC and its application and presentation models because without the Controller, there is no Triad (see Figure 3).
Figure 3 Without the Controller, It Has Been Model-View (not Model-View-Controller)
It’s worth mentioning that it was not only the Controller that caused ambiguity with MVC. With Smalltalk MVC, the business/domain logic is in the Model, and with VisualWorks MVC the ApplicationModel contains the “application” logic required to present one or more business/domain objects to the user (see Figure 4). The “Twisting the Triad” article covers this in more detail. If you consider that the Application Model and Presentation Model have the same functionality, with the distinct difference being that the Presentation Model “cannot” access the View (Martin Fowler made a clear distinction so as not to overload terms), then WPF developers can quickly grasp Presentation Model because it’s in essence MVVM. John Gossman, founding father of MVVM, explains this in his “PresentationModel and WPF” blog entry at bit.ly/pFs6cV. Like Martin Fowler, he was careful not to overload terms. This effectively gives us a clear understanding of what MVVM is; it’s a “WPF-specific version of the PresentationModel pattern.”
Figure 4 VisualWorks Model-View-Controller
Once you can see MVC in its true light, it helps you understand the true roles of the Model and View. These are in essence the only two locations for business/domain logic. After reading “Twisting the Triad,” you can see it was the responsibilities of the Application Model that were moved to the Presenter and that you can’t simply replace the Controller with a Presenter—it wouldn’t make sense, because they aren’t synonymous.
It’s beyond the scope of this article to go into MVP with the attention it deserves; fortunately, there are numerous documents that address it, such as “Twisting the Triad” and the “Potel Paper,” which you can download at bit.ly/dF4gNn (PDF).
I will, however, note that the “Twisting the Triad” article states an important point that I alluded to, which led to the evolution of MVC to MVP:
“Another irritating feature of MVC, at least with respect to Dolphin, was that the idea of a controller did not fit neatly into the Windows environment. Microsoft Windows, like most modern graphical operating systems, provides a set of native widgets from which user interfaces can be constructed. These ‘windows’ already include most of the controller functionality embodied as part of the underlying operating system control.”
I’d also like to highlight from Martin Fowler’s “GUI Architectures” article his statement that “This need to manipulate the widgets directly was seen by many as a bit of dirty workaround and helped develop the Model-View-Presenter approach.” This is important to understand because MVVM has ingrained the Presentation Model mentality into many WPF developers; they believe it’s “bad programming” to update the View directly. This is true for MVVM and the Presentation Model because once you reference the View, you can no longer reuse the ViewModel with a different View (the main reason for this rule). This limiting factor was one of the reasons Smalltalk MVC evolved to the MVP pattern. With MVPVM, developers can access the View and ViewModel directly (it’s tightly coupled), which permits the View and ViewModel to remain completely decoupled (see Figure 5). Views can reuse different ViewModels and ViewModels can be reused by different Views (as you’ll see later when I discuss the MVPVM pattern); this is one of the many great benefits of MVPVM.
Figure 5 Model-View-Presenter, Supervising Controller
Andy Bower shared the following information on the topic with me to provide further clarification:
“It’s perhaps worth pointing out that the aim of all of these patterns is reuse via plugability. Keeping the coupling loose wherever possible and the interfaces as small as possible gives maximum reuse in the way the components can be recombined.
However, note that the Model has effectively two interfaces that must be compatible with any associated View and Presenter. The first is the standard function call interface, used for getting/setting values and performing commands. The second is the event interface, which must be the same as that expected by the View (observer pattern). This combination of interfaces can be referred to as a ‘protocol.’
For example, in Dolphin MVP, a list widget (triad) needs three components with compatible protocols. A ListModel, a ListView and a ListPresenter.”
Once you understand why you don’t want to update a View directly—and realize that this reason contributed to a new design pattern that would permit you to effectively reuse objects by eliminating the constraint of not being able to update the View—then you have the option to embrace the new opportunities that evolution offers. You live in an Agile world and—like your code—you have to change your thought patterns “lest history repeats itself.”
I was taught this pattern early in Prism’s lifecycle, specifically in Drop 7 of the CompositeWPF. Lost in all of the mystical powers of Prism, I recognized the MVP pattern, which helped me find some footing. I quickly learned (as I teach new developers) to simply go to the Presenter and you’ll have your starting point for figuring out the code and application. How code execution gets there can be learned later and doesn’t have to interfere with critical timelines; the impact of the difficult learning curves can be managed.
The following definitions of the MVPVM components have excerpts from “Twisting the Triad” as applicable; I found this information to be informative, comprehensive and accurate, so in the interest of presenting to you the best information possible, I’ll merely quote this article’s definitions. These definitions hold true today for MVPVM (see Figure 6) as they did for MVP back in March 2000 when “Twisting the Triad” was written.
Figure 6 Model-View-Presenter-ViewModel
(Note: Prism is the context of this article, however, MVPVM will work without Prism; the various components will simply be tightly coupled to their implementation versus being resolved—loosely coupled by the Unity or Managed Extensibility Framework [MEF] dependency injection container.)
“This is the data upon which the user interface will operate. It is typically a domain object and the intention is that such objects should have no knowledge of the user interface.” —“Twisting the Triad”
The separation of the Model from the ViewModel is required to address the concerns of dependency injection and its use within the Business Logic Layer (BLL) and Data Access Layer (DAL) to Create, Read, Update, Delete and List (CRUDL) persisted data. In MVPVM, only the DAL has access to the persisted Model objects.
“The behavior of a view in MVP is much the same as in MVC. It is the view’s responsibility to display the contents of a model. The model is expected to trigger appropriate change notifications whenever its data is modified and these allow the view to ‘hang off’ the model following the standard Observer pattern. In the same way as MVC does, this allows multiple views to be connected to a single model.” —“Twisting the Triad”
(Note: I used the preceding quote to emphasize that MVP isn’t a new pattern and that it’s as valid today as it was when MVP evolved from MVC. However, the quote does reference the “Model,” whereas MVPVM uses the “ViewModel.”)
With MVPVM, there’s never a need to have code in codebehind. The Presenter has access to the View and can subscribe to events, manipulate controls and manipulate the UI as required. This proved beneficial while developing the multi-targeted application that accompanies this article. The User ListBox wouldn’t respect the data binding for the selection changed event, so I had to develop a way that would work for all three platforms (because they share the same code). When the View is activated, I call the WireUpUserListBox (see Figure 7, line 174) and use the View to obtain a reference to my lstUserList control (which resides in a DataTemplate). Once it’s found, I wire up to the SelectionChanged event and update the ViewModel SelectedUser property. This works on the desktop, Silverlight and Windows Phone.
Figure 7 Benefits of Being Able to Access the View Directly
A View has no knowledge of the ViewModel, so they aren’t tightly coupled. As long as a ViewModel supports all of the properties to which a View binds, it can easily use the View. The Presenter is responsible for wiring up Views to their ViewModels by setting their DataContext to the applicable ViewModel.
“While it is the view’s responsibility to display model data, it is the presenter that governs how the model can be manipulated and changed by the user interface. This is where the heart of an application's behavior resides. In many ways, an MVP presenter is equivalent to the application model in MVC; most of the code dealing with how a user interface works is built into a presenter class. The main difference is that a presenter is directly linked to its associated view so that the two can closely collaborate in their roles of supplying the user interface for a particular model.” —“Twisting the Triad”
The Presenter will have dependencies on the interfaces for the BLLs from which it needs to retrieve domain objects (data), as shown in the left pane of Figure 8. It will use the resolved instances as configured in the module (see Figure 8, bottom right pane) or bootstrapper to access the data and populate the ViewModel.
Figure 8 Security Module Code
Typically, only the Presenter will be tightly coupled in MVPVM components. It will be tightly coupled to the View, ViewModel and the BLL interfaces. Presenters aren’t intended to be reused; they address specific concerns as well as the business logic/rules for those concerns. In cases where a Presenter can be reused across enterprise applications, it’s likely a module would be better suited for the task—that is, you could create a login module (project) that could be reused by all of your enterprise applications. If you code against an interface, the module can be easily reused using dependency injection technologies such as the MEF or Unity.
“In MVP, the model is purely a domain object and there is no expectation of (or link to) the user interface at all.” —“Twisting the Triad”
This prevents the ViewModel from being tightly coupled to a single View, permitting it to be reused by numerous Views. Likewise, the ViewModel will have no application business logic, so ViewModels can be easily shared across enterprise applications. This promotes reuse and application integration. For example, look at Figure 8, top right pane, line 28. This SecurityCommandViewModel resides in the Gwn.Library.MvpVm.xxxx project (where xxxx = Silverlight, desktop or Windows Phone). Because a User ViewModel will be required in most applications, this is a reusable component. I have to be careful not to pollute it with business logic specific to the demo application. This isn’t a problem with MVPVM, because the business logic will be handled by the Presenter, not within the ViewModel (see Figure 6).
(Note: As the ViewModel properties are populated by the Presenter, they’ll raise NotifyPropertyChanged events, which will alert the View that it has new data—it’s the View’s responsibility to update itself to the ViewModel data upon notification.)
BLLs have no knowledge of the persisted Model data. They work strictly with domain objects and interfaces. Typically, you’ll use dependency injection to resolve your DAL interface within the BLL, so you can later swap out the DAL without affecting any downstream code. Notice in Figure 9, line 34, that I’m using a MockBll implementation for IBusinessLogicLayer for my demo application. Later I can easily replace it with a production implementation of the interface with one line of code because I’ve developed against an interface.
Figure 9 Registering BLL, DAL and Commands
Business logic isn’t limited to the BLLs. In Figure 9, I register named types (for IPresenterCommand) so that I can use dependency injection as a factory. When the user clicks on a button (lines 29–33 in Figure 10), the command parameter is resolved (instantiated) by the baseclass and the applicable command is executed. For example, the LoginCommand (Figure 8, top right pane) is a command that will activate the UserManagerView. All that was required to wire this up was a Button command in XAML and an entry in the SecurityModule (see Figure 8, bottom right pane, line 32).
Figure 10 DataTemplate for the UserCommandViewModel
Persisted domain data could be stored in SQL databases or XML or text files, or retrieved from a REST service. With MVPVM, only the DAL holds specific information required to retrieve data. The DAL will only return domain objects to the BLL. This averts the need for the BLL to have knowledge of connection strings, file handles, REST services and so on. This enhances scalability and extensibility; you can easily switch your DAL from an XML file to a cloud service without affecting any existing code outside of the DAL and the application configuration file. As long as your new DAL unit tests work for the CRUDL processes, you can configure the application to use the new DAL without impacting current applications and their usage.
Thanks to the patterns & practices team, I’ve been able to achieve success for my clients using bleeding-edge technologies and patterns such as MVPVM, without failure. I found that by keeping up with the team’s pace, technologies and patterns, that as newer technologies and patterns emerge, I can pull from past experience to help me more easily find my way in new territory.
MVP is a constant and consistent pattern that I’ve seen used since the earliest days of my architectural studies using patterns & practices projects. To fully appreciate MVP, you have to understand your history, particularly the components of MVC. This isn’t easy, because of the numerous factors discussed.
But by understanding our past, and the reason for our evolution, we can more quickly grasp the need for and power of newer patterns. Even with Prism and all of its complexity and magic, you’ll be able to bypass a difficult learning curve by simply knowing this history and appreciating the need for the newer patterns. In all of the successful projects I’ve been involved with since the emergence of this pattern in early drops of Prism, MVPVM has revealed no issues, speed bumps or brick walls (through evolution they appear to have been eliminated), permitting developers to increase velocity as we build applications that are scalable, extensible and stable.
Bill Kratochvil, an independent contractor, is a lead technologist and architect for an elite team of developers working on a confidential project for a leading company in the medical industry. His own company, Global Webnet LLC, is based in Amarillo, Texas.
Thanks to the following technical experts for reviewing this article: Andy Bower, Christina Helton and Steve Sanderson
At a glance it looks like a very interesting article. Looks like we solve the same problem different ways. [AngryProgrammer] I'd have thought this preferable to having a tightly-coupled Presenter which (it seems to me) is just replacing what you may have put in a View's code-behind or View Model Put 10 programmers in a room with a task and they will exit with 10 successful (different) ways to get it done; it is obvious you "get it" and have come up with a great solution to the problem! However, I have to defend the MVP approach; I choose to learn from, and piggy back on, lessons learned from our great architects. One of the main problems MVP solved was being able to access the view directly - seen "as a bit of dirty work" (as it is today for MVVM). My past and current projects have had "no" limitations, no matter how bizarre the requirements have been. Case in point - the users wanted us to null out the Combobox under a given condition (true story). How did we do it from our Presenter? 5 second one-liner... View.cboMyList.ItemSource = null; We can just as easily bind to any View's components to get their EventArgs which generally hold valuable information. My success on numerous large scale products is a testimony to their efforts to evolve from Application Model and Presentation Model (aka MVVM) to MVP - I'm just jumping on their band-wagon :)
Interesting! I was pointed here by someone commenting on my article here http://www.codeproject.com/Articles/173618/MVVM-sharp-Episode-1 Here I used what I suppose would be classed M-V-VM/VD-C i.e. Model, View, ViewModel/ViewData, Controller The ViewData is just a way of separating ViewModel logic from the actual data payload being bound to a View. The Controller, though, strikes me as an advantage over the Presenter described here, in that it does NOT bind tightly to the View. It handles requests from a ViewModel and Controls the 'flow' of the application. I'd have thought this preferable to having a tightly-coupled Presenter which (it seems to me) is just replacing what you may have put in a View's code -behind or View Model
Please find the article with simple explanation http://pangaluri.wordpress.com/2012/02/06/mvppm-pattern/
In the response that follows I reference a link which bombs out because a period is at the end of the URL. Below is the link for your convenience: My blog on Building Enterprise Composite Applications in C# for Metro WinRt http://www.global-webnet.com/Blog/post/2012/04/03/Building-Enterprise-Composite-Applications-in-C-for-Metro-WinRt.aspx
Thank you for the kind words / feedback. I apologize for the delay in response as I don't get notified when emails are posted. Below are responses to questions posed. Thanks again!
@Curtis E White "I also don't understand the contradictory statement made just before Figure 5. "With MVPVM, developers can access the View and ViewModel directly (it's tightly coupled), which permits the View and ViewModel to remain completely decoupled (see Figure 5)." How can they be tightly coupled and decoupled at the same time?" Hmmm, I guess I should have worded that better... as we learn from early architects, we don't want our view tightly coupled to a view model because you can't reuse it with different view models. Likewise a view model should have no knowledge of the view for the same reason (reuse). So what happens when you have to manually modify a widget in your view - it is not easily done (and to quote Martin Fowler) was seen as a bit of dirty work. Thus MVP emerged which allows you to update both the View and ViewModel. IT IS THE PRESENTER that is tightly coupled to its view and ViewModel(s) so that the View and ViewModel can remain completely decoupled. My bad... @Curtis E White "I also have some difficulty understanding Figure 6. This is MVPVM; okay, I see that, but just exactly where do BLL and DAL fit in?" If you read my blog on Building Enterprise Composite Applications in C# for Metro-WinRt you'll see a diagram from Microsofts Architecture guid (which I reference in the blog) => http://www.global-webnet.com/Blog/post/2012/04/03/Building-Enterprise-... This may help clarify the confusing parts as it is the basis of sound architecture (as outline by the authors of the AppArchGuid.CodePlex.com). In our case we are saying in figure 6 that the Presenter communicates with the Business Logic Layer (BLL). If we code to interfaces then we can easily swap out BLLs and DLLs using IOC contains such as MEF. @ Raharshi Basu roy, "Assuming that a project is going to run on a single platform (Windows Forms) only, isn't it easier to have the ViewModel and the Presenter together as a single class". Hi Raharshi, I wish I could help you but I am not experienced enough on Windows Forms to help you with your question. HOWEVER, http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.h... discusses MVP-VM for Windows Forms and Aviad Ezra has brilliantly taken Windows Forms to a place I didn't think it could be taken.
@Lane, Feltis "I tend to agree with wpleary that MVPVM does not seem to add much value and perhaps will even slow down development. Could you please comment on project sizes / platforms and how that affects which approach is most suitable, MVVM or MVPVM? Thanks!" Hi Lane, my experience in enterprise development is that there are no small projects - sure they start out that way and then they grow as user requirements do and it just becomes another project to maintain. Within enterprise development, I have used MVPVM (as taught by early drops of Prism) to successfully complete both desktop and silverlight projects large and small. Since we used the module concept (reuse of components) it didn't take long to stand up a new application and since all developers understood the pattern it didn't take long for them to ramp up to the framework. On that note I "can't" disagree with wpleary because I work with some of the greatest developers in the world and MVVM, properly implemented, by WPF gurus is an efficient pattern. @Curtis E White "I also don't understand the contradictory statement made just before Figure 5. "With MVPVM, developers can access the View and ViewModel directly (it's tightly coupled), which permits the View and ViewModel to remain completely decoupled (see Figure 5)." How can they be tightly coupled and decoupled at the same time?" Hmmm, I guess I should have worded that better... as we learn from early architects, we don't want our view tightly coupled to a view model because you can't reuse it with different view models. Likewise a view model should have no knowledge of the view for the same reason (reuse). So what happens when you have to manually modify a widget in your view - it is not easily done (and to quote Martin Fowler) was seen as a bit of dirty work. Thus MVP emerged which allows you to update both the View and ViewModel. IT IS THE PRESENTER that is tightly coupled to its view and ViewModel(s) so that the View and ViewModel can remain completely decoupled. My bad...
Bill, Thanks for an excellent article. This is an advanced topic that you shared and will be very well accepted by a fraternity that has done some production work on MVP (Presentation Model) pattern and stumbled upon areas where accessing the view directly seemed the best way but had to take complex workarounds to obey the rules of the pattern. I have worked with the Presentation Model pattern for about 3 years now and I was thinking of a similary pattern for the following reasons - 1. I needed the view to be COMPLETELY free from code-behind, allowing my design team to work on them whichever way they liked. This posed a problem as while working with components from different vendors I found that DataBinding does not always follow the perfect route and intervention was required to synchronise view and model. 2. Too much reliance on data-binding (due to non-accessibility) of the view from Presetation Model was giving me nightmares of memory leaks. Some reference held by the event-handlers can leave a bunch of objects unacceptable for garbage collection causing memory leak. It might be easy to say that "I needed to code well", but while working with a team of developers of different levels of competency, this always posed a problem as not everybody will be able to visualize/foresee a memory leak scenario. Your article came to address just the issues that were troubling me. However, I need to discuss one small thing. Assuming that a project is going to run on a single platform (Windows Forms) only, isn't it easier to have the ViewModel and the Presenter together as a single class. I mean, if I don't have any requirement for the next 5 years for multi-platform compatibility, should I not choose simplicity and speed by combining the ViewModel and Presenter together? That will save me creating a new set of ViewModel classes (for every module) and also thinking about proper wiring up of ViewModel with Presenter. I mean to put it very straight, if I am planning to run only WinForms, can I allow my Presentation Model to access View directly to solve my above issues (data binding with presentation model and handling UI controls directly for special circumstances)? Would eagerly wait for your comment as I am about to begin a complete restructuring of my UI framework based on allowing the "Presentation Model to access View directly" concept. - Rajarshi
Bill- Just stumbled upon your article (and some of your other articles / blogs / etc.) and I'm finding them quite stimulating. I've been thinking about architectural patterns off and on for a while (after stumbling upon Martin Fowler's GUI Architectures paper a year ago). I'm still not quite sure what I think about MVPVM yet but I certainly appreciate your bringing together so many elements here for discussion. I do have a couple of comments / questions. Your comment that "because Microsoft controls (widgets) handle [user input] ... you don't have a need for a Controller..." is well and good, but that doesn't mean the Controller is gone, it's just provided by other elements (widgets), so it would seem that Figure 3 is not quite right. If we're using these widgets in the View, then we've merely subsumed the Controller into the View, at the widget level. Not saying this is good or bad, just that it seems to me that the Controller is still there (implicitly). And the developer better understand how it works (e.g., the Microsoft Event Pattern) or he will not be able to use it. I also don't understand the contradictory statement made just before Figure 5. "With MVPVM, developers can access the View and ViewModel directly (it's tightly coupled), which permits the View and ViewModel to remain completely decoupled (see Figure 5)." How can they be tightly coupled and decoupled at the same time? I also have some difficulty understanding Figure 6. This is MVPVM; okay, I see that, but just exactly where do BLL and DAL fit in? It would seem that this, along with "Domain Models" is all part of the M (Model). BLL is where the (application) model business logic is, DAL is there if we're persisting the data and the Domain Model is the persisted data. It would seem that if there is no (application) data persistence, then DAL and Domain Model "disappear" -- or not? I haven't tried your example here yet and I'm just starting to look at Prism, so perhaps my comments are a bit misdirected, but if I'm a bit confused then others might be as well, so some clarification would be much appreciated. Thanks!
Hi Bill, Thanks for the great article. I just started learning WPF and MVVM a couple of weeks ago. The biggest question that bothers me is VM, declarative and view-agnostic as it is, does not have the full capability of Presenter which can manipulate the view directly in a procedural way. Some of these capabilities can be matched by so work in code-behind but some are very difficult to do. This is concern #1. Concern #2 is V-first vs. VM-first. The pros and cons of each (http://stackoverflow.com/questions/3763072/what-are-the-pros-and-cons-of-view-first-vs-viewmodel-first-in-the-mvvm-pattern) are clearly non-resolvable without introducing a third class, as suggested in this article (http://wildermuth.com/2009/5/22/Which_came_first_the_View_or_the_Model). Concern #3 is when reusing external control that is written in MVP or MVP-Factory pattern, I still need some kind of VM (as opposed to the raw Model) to feed the presenter or the factory. The data transformation from M to VM can be done in the VM class, however, the view-creation/feeding/update logic needs a home. To address these concerns, I was thinking about a MVHVM (M-V-Hosting-VM) pattern. But since I am new to this field, I couldn't be sure if this is only because I missed or misunderstood something. Your article confirmed my understanding that this Hosting/Presenter class is indeed needed.
Hi Bill, Great article, it is tough to find much on MVPVM since it is so new, but this provides a good starting background. At my work we are considering whether or not to begin practicing MVPVM, so recently I have been reading up on all of this and correct me if I am wrong, but I believe that the main reason to use MVPVM is because... You are developing for multiple platforms (mobile, desktop, web) and use different technologies for display (Silverlight, WPF, Smartphone), so it is beneficial to use MVPVM to minimize the number of Views and ViewModels necessary to support all platforms (display-wise and functional-wise), because containing the logic inside the presenter makes it easier to support these different platforms and technologies. If, for example, you are working on a WPF desktop application that will be used only in Windows, I tend to agree with wpleary that MVPVM does not seem to add much value and perhaps will even slow down development. Could you please comment on project sizes / platforms and how that affects which approach is most suitable, MVVM or MVPVM? Thanks! Lane
@hamling-ling: I fixed the link. I had moved servers and missed this folder - my apologies! @Maxipes Fikus: Thank you for your feedback, you bring up an excellent point - I should have clearly summarized the fact that a MVC controller was a class that handled user input (gestures), packaged them up, and sent messages to subscribing classes - just as Microsoft controls do under the hood, i.e., You don't have to poll the keyboard buffer (like controllers had to) to see if a character is typed, you subscribe to an event and are notified when a character is received. Because Smalltalk didn't have this luxury they created controllers to handle the task. When smart controls came out the controller became obsolete. It is then important to understand that business logic use to be in the "Model" NOT controller; so you can't say a controller and presenter are synonymous. When the controller received a keystroke it was the “model” that would receive the message and process it as applicable (the controller did not have any business logic in it). Thus with the absence of a controller the need for MVP arose, the business logic was moved out of the model into the presenter (twisting the triad) and the presenter became responsible for updating the model (pure domain object) which the view observed (observer pattern). The “presenter” could subscribe to a view’s control events and perform actions as applicable. Only after summarizing would it have been appropriate for me to provide all of the supporting documentation, which you could skip over or read, so that you could discern for yourself whether or not I interpreted a topic that so many people misinterpret. Fortunately I had folks like Andy Bower (author of Twisting the Triad and one of the founding father of MVP) help me through the process years ago when I was trying to figure out why we had to evolve from MVC to MVP.
I can't download the code sample. The link http://amarillo.us.com/MSDN/MvpVmR2.zip seems to be wrong. Is there any other way to get the sample ?
I found the style of this article quite confusing. Instead of a bunch of quotes from various articles and books mixed together, I think a simle and clear explanation of - for instance - what a MVC and a Controler is would be much worthy. Thanks for considering this issue instead of just deleting unpopular comments.
I found the style of this article extremely confusing. There is a lot of quotes from various articles and book mixed together, (I have counted juts “Twisting the Triad” mentioned about fourteen times). This brings a nice picture about what the author has read about the topic, together with his opions about it; together with a bunch of references to Smalltalk (I have never worked with Smalltalk, and do not wish to). But in this mixup, there is no simple and clear explanation for instance what is the Controller, not mentioning the subsequent information which I did not get into, rather stopping in the middle.
@dotnetnate - Thank you and I agree, it is one of the reasons I wrote the article so that I can minimize "a lot of explanation as to WHY you want all of these parts operating independently of each other"
@Fábio Augusto Pandolfo - I am far removed from WinForms but from the diagrams it appears we are saying the same thing, he is applying it to the WinForms environment (which is very impressive!) where I am applying the same principles to Composite WPF applications using Prism and IOC. The confusion may be in the notion that he is overloading the term "View Model" which is generally used with WPF.
Good post. I use this style of variant for web applications as well. One of my biggest frustrations with a lot of the MVC examples that are out there (and some even espoused by Microsoft) is that they may be great for demoing a technology, but they aren't great for scaling to large applications. Unfortunately this leads to having to do a lot of explanation as to WHY you want all of these parts operating independently of each other and having to undo a lot of 'training' that's been performed by Microsoft.
what about this pattern: http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.h... it uses the same name, I got confused.
@BunburyJa - if you look at the released source code for http://PasswordMgr.Codeplex.com I actually used the Prism 4 and Unity 2 libraries for the desktop and Silverlight applications. I was forced to use my homegrown for Silverlight for phone. You could actually swap out my homegrown for the accompanying Desktop/Silverlight applications and it will compile and work - I added only the homegrown to keep the package smaller. @Jsoar - good point on the "pre-requisites", I'll be sure to take the extra step to comply with this (even if I have to set up a virtual environment). Particularly since I did have to spend the energy doing so in emails (directly to me) following the article. @Berryl - my apologies! I do not get email notifications and this is the first I saw that I have had comments. I hope you were taking care of by jsoar @WpLeary - I work with some of the brightest developers on the planet, many of them WPF gurus that can make WPF walk, talk and do backflips; I agree with you; MVVM in the hands of a guys like these can do anything! I on the other hand am a plumbing and infrastructure kinda guy and I ran into some of the many issues the caused the evolution of Presentation Model (MVVM) to MVP; learning from past architects was invaluable to resolve issues we encountered. MVP-VM was a way, taught to me via Prism samples by the P&P team when Prism was barely out of the box (I think it was drop 7). It solved the many issues I ran into so I am merely sharing what I learned as "a solution" not necessarily "the solution" - please reference the following blog for more on the topic (http://www.global-webnet.com/Blog/post/2011/12/17/Notes-on-software-architecture-there-are-no-experts.aspx)
As a big fan of MVVM, and a big proponent of it at my company, I was eager to read this article. I ended up being extremely disappointed. The entire purpose and power of view models is lost. View models are not intended to be reusable or "shared easily across enterprise applications"; they are models of a specific view, that allow you to design and *unit test* that view's logic without regard to the view specifics, such as what types of controls are used. And its examples of how the Presenter is wired into the controls and events of the View?! This completely defeats the purpose of using the view model pattern: you get this for free via data binding and commands. You mention "The User ListBox wouldn't respect the data binding for the selection changed event." I have never seen that, though I have not done phone development yet, so perhaps that was the environment you were in. But, in the rare instance where data binding does not work, 9 times out of 10 a converter or custom control that derives from the base control you are having issues with will serve as a workaround. I think this article will really make it harder for someone to learn modern WPF/SL development, and do not view what you propose as an evolution of MVVM. WPF enabled profoundly new (and fabulous) ways of doing things through data binding and commanding and this article ignores nearly all of that.
Hi Bill, I like the work you have done on this pattern. Is there any reason not to use the Prism 4 and Unity 2 libraries and extend. Instead you have done some repackaging.
Hi - Enjoyed the article, but I had issues to Berryl with the source code. What I did to 'fix' it: * Installed latest Windows Phone / Siliverlight tools (I have no link for this, but relatively easy to find) * Re-ran VS 2010 SP1 from ISO file (also easy to find). * Installed Unity 2.0 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9093) and ran the 'reister' batch file. * Installed Prism4 (http://www.microsoft.com/download/en/confirmation.aspx?id=4922) * Installed the Portable Library Tools (http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981/) I can now successfully load, build, and run the sample project. In the future, it would be nice to have the above 'pre-requisites' clearly listed for this and other MSDN articles.
Yeah, I cannot get your Portable projects to load...
The code sample is definitely *not* trivial, but I can't compile it. Is there a Read Me that I missed? Phone dev seems to be the problem on my 2010 professional ide, but can you please provide some guidance? Thanks! Error: <Import Project="$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets" />
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.