DevExpress MVVM Framework. Introduction to POCO ViewModels.

03 December 2013


  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.
  9. DevExpress MVVM Framework. Behaviors.
  10. DevExpress MVVM Framework. TaskbarButtonService, ApplicationJumpListService and NotificationService.
  11. DevExpress MVVM Framework. Asynchronous Commands.
  12. DevExpress MVVM Framework. Converters.


Traditionally, 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; }
  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:     }
   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: }
   1: <UserControl x:Class="DXPOCO.Views.LoginView"
   2:     xmlns:dxmvvm=""
   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:     }
  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; }
   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) {
   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.


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:     }
  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:     }
   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) {
   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:     }
  15:     public void SaveCore() {
  16:         //...
  17:     }
  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:     }
   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: }

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:
  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));

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).

18 comment(s)
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?

4 December, 2013
Alex Chuev (DevExpress)

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.


6 December, 2013
Geert Depickere


You might want to check out Fody assembly weaver (and an example of a similar use of it in the Catel project at

6 December, 2013
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, 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.

10 December, 2013
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).

18 December, 2013
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>()));

19 December, 2013
John Leed

Alexander, we're using MVVM Light now, but this looks compelling. Would this work with injection using Castle Windsor?

1 May, 2014
Alexander (DevExpress Support)


Yes, it is possible to do this. You can create a custom component activator. For instance:

   public class POCOViewModelActivator : DefaultComponentActivator {

       public POCOViewModelActivator(ComponentModel model, IKernelInternal kernel, ComponentInstanceDelegate onCreation, ComponentInstanceDelegate onDestruction)

           : base(model, kernel, onCreation, onDestruction) {

               Model.Implementation = TryGetPOCOType(Model.Implementation);


       Type TryGetPOCOType(Type implementation) {

           if(implementation.GetCustomAttribute<POCOViewModelAttribute>() != null) {

               implementation = ViewModelSourceHelper.GetProxyType(implementation);


           return implementation;



4 May, 2014
Alexander (DevExpress Support)

Then, register the POCOViewModelActivator:

   public class ApplicationInstaller : IWindsorInstaller


       public void Install(IWindsorContainer container, IConfigurationStore store)




               Classes.FromThisAssembly().Where(type => type.HasAttribute<DevExpress.Xpf.Mvvm.DataAnnotations.POCOViewModelAttribute>())

                   .Configure(r => r.Activator<POCOViewModelActivator>())





4 May, 2014
Mark Meyer - Civic

Hi Alexander,

This is great stuff.  I'm having an issue with the new method of creating the MessageBoxService.  It's always null when I try to use it.  I've defined it as described above.  Is there something else I need to do?

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

21 August, 2014
Mark Meyer - Civic

Sorry, I figured it out.  I still had a mix of the ViewModelBase implementation and POCO implementation.  I cleaned it up and it works as expected.

21 August, 2014
Alexander (DevExpress Support)

Hi Mark,

Thank you for your feedback.

I am happy to hear that the issue is resolved and our POCO works correctly :-)

22 August, 2014
Michael Piber 1


In our WPF application we are using MEF ( for importing our WCF Services.

Is there a way to combine MEF with POCOViewModels?

We could only manage to use ServiceLocator.Current.GetInstance<ISomeWCFService> in the default ctor, but with this solution we cannot easily test our ViewModels.

We want to use either an [ImportingConstructor] or the Attribute [Import] on the property ISomeWCFService when using POCOViewModel. But both ways are not working?

Any tips/ideas?

16 June, 2015
Michael Ch (DevExpress Support)


Sure, it is possible. However, it is necessary to consider each case separately, because there may be a lot of different nuances. I would like to ask you to create a ticket in our Support Center, because your question is technical and requires creating a sample project to demonstrate specifics of your application, which cannot be provided in a blog comment. So, please contact our support team. We will be happy to assist you.

17 June, 2015
Paul Harrington

Any update on dropping the requirement to create properties as virtual?

17 August, 2015
Alexander (DevExpress Support)

Hi Paul,

No, the virtual modifier is required. ViewModelSource creates a class descendant at runtime with overridden properties. Since it is not possible to override not-virtual properties, it is impossible to get rid of the virtual modifier.

18 August, 2015

I don't see DevExpress.Xpf.Mvvm.DataAnnotations.POCOViewModel  but I do see DevExpress.Mvvm.DataAnnotations.POCOViewModel

What should be used?

21 October, 2016
Alexander (DevExpress Support)


We changed this namespace in version 14.1. This is an old post, so I recommend you use our documentation instead.

Here, you can find the most actual information:

21 October, 2016

Please login or register to post comments.