Blogs

WPF and Silverlight

DevExpress MVVM Framework. Introduction to POCO ViewModels.

v4Traditionally, MVVM development means writing significant ViewModel boilerplate for bindable properties and commands. Even after extending the DevExpress.Xpf.Mvvm.ViewModelBase class, you need at least five lines of code to declare a single bindable property and several more to define a command:

NOTE: Refer to the following topic to explore the ViewModelBase class: Getting Started with DevExpress MVVM Framework. Commands and View Models.

   1: public class LoginViewModel : ViewModelBase {
   2:     string userName;
   3:     public string UserName {
   4:         get { return userName; }
   5:         set { SetProperty(
   6:             ref userName, value, () => UserName);
   7:         }
   8:     }
   9:     public DelegateCommand<string> 
  10:         SaveAccountCommand { get; private set; }
  11:  
  12:     public LoginViewModel() {
  13:         SaveAccountCommand = 
  14:             new DelegateCommand<string>(
  15:             SaveAccount, CanSaveAccount);
  16:     }
  17:     void SaveAccount(string fileName) {
  18:         //...
  19:     }
  20:     bool CanSaveAccount(string fileName) {
  21:         return !string.IsNullOrEmpty(fileName);
  22:     }
  23: }
 
With many bindable properties declared, it becomes a real nightmare if an error is raised in a property setter: as when passing the incorrect field to a setter or setting the incorrect property from a lambda expression. Worse, it is just not beautiful.

Now imagine, instead of the preceding code, writing this:

   1: public class LoginViewModel {
   2:     public virtual string UserName { get; set; }
   3:     public void SaveAccount(string fileName) {
   4:         //...
   5:     }
   6:     public bool CanSaveAccount(string fileName) {
   7:         return true;
   8:     }
   9: }


The 13.2 release makes it possible, with support for POCO ViewModels. Generate a full-fledged ViewModel from your POCO class with ViewModelSource.

In code:

   1: public class LoginViewModel {
   2:     protected LoginViewModel() { }
   3:     public static LoginViewModel Create() {
   4:         return ViewModelSource.Create(() => new LoginViewModel());
   5:     }
   6:  
   7:     public virtual string UserName { get; set; }
   8:     public void SaveAccount(string fileName) {
   9:         //...
  10:     }
  11:     public bool CanSaveAccount(string fileName) {
  12:         return !string.IsNullOrEmpty(fileName);
  13:     }
  14: }
 
In XAML:
 
4.Blog.Messaging.003
 
   1: <UserControl x:Class="DXPOCO.Views.LoginView"
   2:     xmlns:dxmvvm="http://schemas.devexpress.com/winfx/2008/xaml/mvvm"
   3:     xmlns:ViewModels="clr-namespace:DXPOCO.ViewModels"
   4:     DataContext="{dxmvvm:ViewModelSource Type=ViewModels:LoginViewModel}"
   5:     ...>
   6:     <Grid>
   7:         <!--...-->
   8:     </Grid>
   9: </UserControl>

 

ViewModelSource uses System.Reflection.Emit to dynamically create and return an instance of a descendant of the passed ViewModel. The approximate code of the descendant is:

   1: public class LoginViewModelBindable : LoginViewModel, INotifyPropertyChanged {
   2:     public override string UserName {
   3:         get { return base.UserName; }
   4:         set {
   5:             if(base.UserName == value) return;
   6:             base.UserName = value;
   7:             RaisePropertyChanged("UserName");
   8:         }
   9:     }
  10:     DelegateCommand<string> saveAccountCommand;
  11:     public DelegateCommand<string> SaveAccountCommand {
  12:         get {
  13:             return saveAccountCommand ?? 
  14:                 (saveAccountCommand = 
  15:                 new DelegateCommand<string>(SaveAccount, CanSaveAccount));
  16:         }
  17:     }
  18:  
  19:     //INotifyPropertyChanged Implementation
  20: }

Now let’s examine how to control ViewModel generation.

Bindable Properties

The rules for generating bindable properties are simple: ViewModelSouce creates bindable properties for public virtual properties and automatic properties with a public getter and, at the least, a protected setter.

You can define functions to invoke when a property is changed. These functions need a special name: On<PropertyName>Changed, On<PropertyName>Changing:

   1: public class LoginViewModel {
   2:     public virtual string UserName { get; set; }
   3:     protected void OnUserNameChanged() {
   4:         //...
   5:     }
   6: }
   1: public class LoginViewModel {
   2:     public virtual string UserName { get; set; }
   3:     protected void OnUserNameChanged(string oldValue) {
   4:         //...
   5:     }
   6:     protected void OnUserNameChanging(string newValue) {
   7:         //...
   8:     }
   9: }

Use the BindableProperty attribute to set a function not matching the convention:

   1: public class LoginViewModel {
   2:     [BindableProperty(isBindable: false)]
   3:     public virtual bool IsEnabled { get; set; }
   4:  
   5:     [BindableProperty(OnPropertyChangedMethodName = "Update")]
   6:     public virtual string UserName { get; set; }
   7:     protected void Update() {
   8:         //...
   9:     }
  10: }

The disadvantage of this approach is renaming a function or property causes its handler to stop working. This is why we also implemented support for fluent declaration. Use the Fluent API as follows:

   1: [MetadataType(typeof(Metadata))]
   2: public class LoginViewModel {
   3:     class Metadata : IMetadataProvider<LoginViewModel> {
   4:         void IMetadataProvider<LoginViewModel>.BuildMetadata
   5:             (MetadataBuilder<LoginViewModel> builder) {
   6:  
   7:             builder.Property(x => x.UserName).
   8:                 OnPropertyChangedCall(x => x.Update());
   9:             builder.Property(x => x.IsEnabled).
  10:                 DoNotMakeBindable();
  11:         }
  12:     }
  13:     public virtual bool IsEnabled { get; set; }
  14:     public virtual string UserName { get; set; }
  15:     protected void Update() {
  16:         //...
  17:     }
  18: }

This approach avoids errors during refactoring.

NOTE: We will return to the Fluent API in an upcoming post to examine other tasks to solve with it.

Commands

A command is generated for each parameterless and single parameter public method.

   1: public class LoginViewModel {
   2:     //DelegateCommand<string> SaveAccountCommand =
   3:     //    new DelegateCommand<string>(SaveAccount, CanSaveAccount);
   4:     public void SaveAccount(string fileName) {
   5:         //...
   6:     }
   7:     public bool CanSaveAccount(string fileName) {
   8:         return !string.IsNullOrEmpty(fileName);
   9:     }
  10:  
  11:     //DelegateCommand Close = new DelegateCommand(Close);
  12:     public void Close() {
  13:         //...
  14:     }
  15: }

Likewise, command generation can be controlled with the Command attribute or Fluent API:

   1: public class LoginViewModel {
   2:     [Command(isCommand: false)]
   3:     public void SaveCore() {
   4:         //...
   5:     }
   6:  
   7:     [Command(CanExecuteMethodName = "CanSaveAccount",
   8:         Name = "SaveCommand",
   9:         UseCommandManager = true)]
  10:     public void SaveAccount(string fileName) {
  11:         //...
  12:     }
  13:     public bool CanSaveAccount(string fileName) {
  14:         return !string.IsNullOrEmpty(fileName);
  15:     }
  16: }
 
   1: [MetadataType(typeof(Metadata))]
   2: public class LoginViewModel {
   3:     class Metadata : IMetadataProvider<LoginViewModel> {
   4:         void IMetadataProvider<LoginViewModel>.BuildMetadata
   5:             (MetadataBuilder<LoginViewModel> builder) {
   6:  
   7:                 builder.CommandFromMethod(x => x.SaveCore()).
   8:                     DoNotCreateCommand();
   9:                 builder.CommandFromMethod(x => x.SaveAccount(default(string))).
  10:                     CommandName("SaveCommand").
  11:                     CanExecuteMethod(x => x.CanSaveAccount(default(string)));
  12:         }
  13:     }
  14:  
  15:     public void SaveCore() {
  16:         //...
  17:     }
  18:  
  19:     public void SaveAccount(string fileName) {
  20:         //...
  21:     }
  22:     public bool CanSaveAccount(string fileName) {
  23:         return !string.IsNullOrEmpty(fileName);
  24:     }
  25: }

The extension methods of the DevExpress.Xpf.Mvvm.POCO.POCOViewModelExtensions class support manually raising a PropertyChanged event or updating a command:

   1: public static class POCOViewModelExtensions {
   2:     public static bool IsInDesignMode(this object viewModel);
   3:     public static void RaiseCanExecuteChanged<T>(
   4:         this T viewModel, Expression<Action<T>> methodExpression);
   5:     public static void RaisePropertyChanged<T, TProperty>(
   6:         this T viewModel, Expression<Func<T, TProperty>> propertyExpression);
   7: }

For instance:

   1: public class LoginViewModel {
   2:     public void Update() {
   3:         this.RaisePropertyChanged(x => x.UserName);
   4:         this.RaiseCanExecuteChanged(x => x.SaveAccount(default(string)));
   5:     }
   6:  
   7:     public virtual string UserName { get; set; }
   8:     public void SaveAccount(string fileName) {
   9:         //...
  10:     }
  11:     public bool CanSaveAccount(string fileName) {
  12:         return !string.IsNullOrEmpty(fileName);
  13:     }
  14: }
Services

As you likely know, the DevExpress MVVM Framework provides a service mechanism. Previously, accessing a service required inheriting from ViewModelBase and implementing the following construction:

   1: public IMessageBoxService MessageBoxService { 
   2:     get { return GetService<IMessageBoxService>(); } 
   3: }

You can now write:

   1: public virtual IMessageBoxService MessageBoxService { get { return null; } }

Use the ServiceProperty attribute or the Fluent API, as earlier described, to control service property generation.

 

Is there a performance penalty for working with POCO?

The ViewModel created by ViewModelSource is a descendant of the passed class. This descendant is generated using System.Reflection.Emit to implement INotifyPropertyChanged, override virtual properties, create commands, etc. Although these operations are handled at runtime, performance degradation is not an issue because the mechanism uses a cache -- generation is performed once only for each class and not for each instance of a class. By the way, Entity Framework 5.0+ uses the same mechanism.

ViewModelSource supports several approaches to create ViewModels.

  1. For a ViewModel with a public parameterless constructor, the following approach is simple and fast:
    ViewModelSource.Create<LoginViewModel>();
  2. Since lambda expressions are not comparable, they remain uncached and compiled anew with each method call. While this approach is the most powerful and beautiful, it is also the slowest:
    ViewModelSource.Create(() => new LoginViewModel(caption: "Login") {
    UserName = "John Smith"
    });
  3. Since compiled delegate instances can be cached, this is a fast approach for passing parameters to the ViewModel constructor: 
    var factory = ViewModelSource.Factory((string caption) => new LoginViewModel(caption));
    factory("Login");

Is there a live example of POCO ViewModels?

With 13.2, we introduce a new real-life demo – Sales. This demo is built completely on the POCO technology, so you can examine its code.

Moreover, DevExpress Scaffolding Wizards now generate ViewModels as POCO. Here is a tutorial describing how to build an application with Scaffolding Wizards. You can also scaffold Views based on your POCO ViewModels - simply add the DevExpress.Xpf.Mvvm.DataAnnotations.POCOViewModel attribute to the ViewModels.

P.S. What could be better than the previous approach? Right, dropping the requirements of virtual properties and creating ViewModel instances via a special factory. We are currently working on this and will introduce a solution in the near future.

P.P.S. In fact, the POCO ViewModels functionality is a good example of the Aspect-oriented Programming paradigm. Previously, inheriting from ViewModelBase meant implementing cross-cutting concerns across ViewModels (i.e. similar code in the definitions of the bindable properties and commands). Now, you can get rid of this redundant code with aspects (e.g., conventions for defining properties and methods, attributes, and Fluent API).

OTHER RELATED ARTICLES:

  1. Getting Started with DevExpress MVVM Framework. Commands and View Models.
  2. DevExpress MVVM Framework. Introduction to Services, DXMessageBoxService and DialogService.
  3. DevExpress MVVM Framework. Interaction of ViewModels. IDocumentManagerService.
  4. THIS POST: DevExpress MVVM Framework. Introduction to POCO ViewModels.
  5. DevExpress MVVM Framework. Interaction of ViewModels. Messenger.
  6. DevExpress MVVM Framework. Using Scaffolding Wizards for building Views.
  7. DevExpress MVVM Framework. Data validation. Implementing IDataErrorInfo.
  8. DevExpress MVVM Framework. Using DataAnnotation attributes and DevExpress Fluent API.
Published Dec 04 2013, 03:40 AM by
Bookmark and Share

Comments

Dean J.

So, what platforms are you talking about?  I see XAML, so I'm assuming WPF/Win 8.  Anything here that WinForms can take advantage of?

December 4, 2013 9:54 PM

Alexander Ch (DevExpress Support)

Hi Dean,

That’s a good question. Currently, POCO ViewModels are supported in WPF and Silverlight. The Windows 8 XAML technology does not expose the System.Reflection.Emit namespace, so it is impossible to use POCO ViewModels there. However, we are going to support POCO ViewModels creation without ViewModelSource. This approach will work at the compile time and will not be based on System.Reflection.Emit. Hence, it should work in the Windows 8 XAML platform.

Although we created the POCO ViewModels mechanism especially for XAML-based platforms, you can also use it in Windows Forms in code behind if you add a reference to the DevExpress.Xpf.Mvvm library to your project.

Thanks

December 6, 2013 2:02 AM

Geert Depickere

Alexander,

You might want to check out Fody assembly weaver (and an example of a similar use of it in the Catel project at www.catelproject.com/.../catel-fody)

December 6, 2013 8:23 AM

Alexander (DevExpress Support)

Hi Geert,

Yes, thank you for pointing out this approach to us. It is an interesting solution and we will research it.

I would also say that we know about other products on the market that provide similar functionalities (for instance, PostSharp, http://www.postsharp.net). The reason why we decided to create our own solution is that we aim to provide everything you need for your development. That's it.

December 10, 2013 1:40 AM

Neven Zovko

Alexander, this is really great stuff. More of this, please. Looking forward to see examples of POCO ViewModels interacting with frameworks like MS Unity for implementing cross-cutting logic like logging, progress reporting and similar stuff (using interception).

December 18, 2013 11:38 PM

Alexander (DevExpress Support)

Hi Neven,

Thank you for your feedback.

In the future, we are going to add the capability to create POCO classes at the compile time. Then, you will not need to be concerned about integration with Unity. These two technologies will work separately.

For now, it is also possible to use POCO classes with the Unity Interception technology. You only need to register your ViewModels in the UnityContainer in a special way:

container.RegisterType<POCOViewModel1>(new InjectionFactory(x => ViewModelSource.Create<POCOViewModel1>()));

December 19, 2013 6:04 AM
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, Silverlight, ASP.NET, WinForms, HTML5 or Windows 8, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2014 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners