In 2004 Martin Fowler published an article about a template called the Presentation Model (PM). The Presentation Model pattern is similar to MVP in that it separates the presentation from its behavior and state. The curious part of the PM pattern is that it creates an abstraction of the presentation called a presentation model. The representation thus becomes simply the result of processing the presentation model. According to Fowler, the presentation model constantly updates its representation, so they remain synchronized with each other. This synchronization logic exists as code in the presentation model classes.

In 2005, John Gossman, now one of the WPF and Silverlight architects at Microsoft, blogged about the presentation model-presentation-model (MVVM) pattern. MVVM is the same as Fowler’s presentation model in that. both patterns contain a presentation abstraction containing the state and behavior of the presentation. Fowler introduced the presentation pattern as a way to create a platform-independent user interface of a view abstraction, and Gossman proposed MVVM as a standardized way to use core WPF features to simplify the creation of user interfaces. In this sense, I consider MVVM to be a private variant of the more general PM pattern, tailored for WPF and Silverlight platforms.

Glenn Block’s excellent article “Prism: Patterns for building composite applications with WPF” in the September 2008 issue describes Microsoft’s guidance on composite applications for WPF. The term ViewModel is not used. The term presentation model is used to describe the abstraction of a view. However, in this article, I will refer to the pattern by the abbreviation MVVM, and to the view abstraction as a presentation model. In the WPF and Silverlight communities, this terminology is much more common.

Unlike a presenter in MVP, a presentation model does not need to reference a view. The presentation binds to the properties of the presentation model, which in turn represents the data in the model objects and other states needed for that presentation. Bindings between a view and a view model are easy to create because the view model object is set as the DataContext of the view. If values in the view model change, those new values are automatically transferred to the view through data binding. When the user clicks a button in the view, a command in the view model is executed to perform the desired action. All changes to model data are always made by the view model, not the view.

The representation classes are unaware of the existence of the model classes, and the representation model and the model are unaware of the representation. The model actually has no idea at all that the representation model and the representation exist.

The post Evolution of the model-representation-model-representation pattern appeared first on Mvvmlight.

Now let’s understand what each of the three parts in the name means:

• Model is the logic that is associated with the application data.
• In other words, it is POJO, classes for working with API, database, etc.
• View – actually, this is the layout of the screen, where all the necessary widgets for displaying information are located.

ViewModel – an object that describes the logic of View behavior depending on the result of Model. You can call it a model of View behavior. It can be either text formatting, or the logic of controlling the visibility of components or displaying states such as loading, error, blank screens, etc. It also describes behavior that has been initiated by the user (text input, button click, swipe, etc.)

So what does this give us in the end?

• Flexibility of development. This approach increases the convenience of working in a team, because while one team member is working on the layout and styling of the screen, another one is describing the logic of data acquisition and processing;
• Testing. This structure simplifies writing tests and the process of creating mock-objects. Also, in most cases there is no need in automated UI-testing, because you can wrap unit-tests with ViewModel itself;
• Logic delimitation. Due to greater delineation, the code becomes more flexible and easier to maintain, not to mention readable. Each module is responsible for its specific function and only that.

Since nothing is perfect, there are disadvantages:

• For smaller projects, this approach may not be justified.
• If the data binding logic is too complex – it will be a bit more difficult to debug the application.

The post What is MVVM? appeared first on Mvvmlight.

The most important aspect of WPF that makes MVVM a very convenient pattern is the data binding infrastructure. By binding view properties to the view model, a loose coupling of these components is obtained, which completely frees the developer from having to write code in the view model that directly updates the view. The data binding system also supports input validation, providing a standardized path for passing validation errors to the view.

Two other WPF features that make this pattern so useful are data templates and the resource system. Data templates apply views to the view model objects shown in the user interface. You can declare templates in XAML code and let the resource system automatically find and apply these templates for you at runtime. To learn more about data binding and templates, see my July 2008 article “Data and WPF. Customizing data display using data binding and WPF”.

If WPF didn’t have command support, the MVVM pattern wouldn’t be so versatile. In this article, I will show you how a view model can provide commands to a view, thus allowing it to use its functions. If you are not familiar with the command system, I suggest you read Brian Noyes’ extensive article “WPF for Connoisseurs. Getting to Know Routed Events and Commands in WPF”, in the September 2008 issue.

In addition to the WPF (and Silverlight 2) features that make MVVM a natural way to structure an application, this pattern is also popular because the classes of the view model lend themselves easily to unit testing. If the application’s interaction logic is in a set of view model classes, it is easy to write code that tests it. In a sense, views and unit tests are different types of view model consumers. A test suite for an application’s view model provides free and fast regression testing that reduces the cost of maintaining the application in the future.

In addition to the convenience of composing automatic regression tests, the testability of presentation model classes can help to properly design user interfaces for which it is easy to make design themes. When designing an application, you can often decide whether to put something in the view or in the view model by imagining whether you will need to write a unit test that consumes the view model. If you can write unit tests for the view model without creating UI objects, you can also encapsulate the view model completely in a design theme, since it has no dependencies on specific visual elements.

Finally, for developers collaborating with visual designers, using MVVM makes it easy to create a continuous flow of work between the designer and the developer. Since a view is nothing more than an optional consumer of the view model, it is not difficult to remove one view and replace it to represent the view model with a new one. This simple action allows rapid prototyping and evaluation of user interfaces made by the designers.

The development team can focus on creating stable classes of the view model, while the design team can focus on user-friendly views. It takes little more than checking that the correct bindings exist in the view’s XAML file to bring together the results of both teams’ work.

The post Why WPF developers love MVVM so much appeared first on Mvvmlight.

There are popular design patterns that help tame this monster, but the task of properly separating the many issues and resolving them can be difficult. The more complex the patterns, the more likely it is that simplifications will then be used that devalue all previous attempts to make things the best they can be.

Design patterns are not always to blame. Sometimes we use complex design patterns for which we need to write a lot of code because the UI platform being used is not compatible with the simpler pattern. What we need is a platform that allows us to create user interfaces using simple, time-tested, and programmer-approved design patterns. Fortunately, Windows Presentation Foundation (WPF) provides just that.

As WPF becomes more and more recognized in the world of programmers and users, the WPF community is developing its own “ecosystem” of patterns and practical guidelines. In this article, I’ll explore some of these practical guidelines for designing and implementing client applications in WPF. Using the core features of WPF along with the Model-View-View-View-Model (MVVM) design pattern, I’ll walk through a sample program that shows that it’s not hard at all to do a WPF application “right”.

By studying this article, you’ll learn how to fit together data patterns, commands, data binding, resource system, and the MVVM pattern to create a simple, testable, and robust infrastructure in which any WPF application can thrive. The sample program that accompanies this article can serve as a template for a real WPF application that uses MVVM as the underlying architecture. The unit tests in the sample solution show how easy it is to test the application’s user interface features when those features are represented by a set of ViewModel classes. Before we dive into the details, let’s first consider why we should use a pattern like MVVM.

Order vs. Chaos

Using design patterns in a simple program like “Hello, world!” is unnecessary and even harmful. Any skilled developer will immediately understand a couple lines of code. But as the number of program features increases, so does the number of lines of code and moving parts. At some point, the complexities of the system and its inherent problems force developers to organize code so that it is easier to understand, discuss, extend, and troubleshoot. We reduce the cognitive chaos of a complex system by naming certain elements of the source code with known names. We define the name assigned to a piece of code by its functional role in the system.

Developers often intentionally structure code according to a design pattern, not allowing patterns to emerge naturally. Both approaches are good, but in this article I’ll discuss the benefits of directly using MVVM as the architecture for a WPF application. Some class names include known terms from the MVVM pattern, such as the ending “ViewModel” if the class is a view abstraction. This approach helps avoid the cognitive chaos mentioned above. Instead, you can happily stay in a state of controlled chaos, the natural state of affairs in most professional software development projects!

The post WPF applications with model-representation design pattern appeared first on Mvvmlight.