[Expand]General Information
[Collapse]WinForms Controls
  .NET Core Support
 [Expand]What's Installed
 [Collapse]Build an Application
  [Expand]Choose Application UI
  [Expand]Printing and Exporting
  [Collapse]WinForms MVVM
     Conventions and Attributes
     Data Bindings and Notifications
     Layer Communication. Messenger
     Fluent API Support
     View Management
     ViewModel Management
   [Expand]Design-time Support
  [Expand]Right-to-Left Layout
   Redistribution and Deployment
   How to: Perform Actions On Application Startup
 [Expand]Controls and Libraries
 [Expand]Common Features
  Get More Help
 [Expand]API Reference
[Expand]ASP.NET Controls and MVC Extensions
[Expand]ASP.NET Bootstrap Controls
[Expand]ASP.NET Core Bootstrap Controls
[Expand]WPF Controls
[Expand]Xamarin Controls
[Expand]Windows 10 App Controls
[Expand]Office File API
[Expand]Report and Dashboard Server
[Expand]eXpressApp Framework
[Expand]eXpress Persistent Objects
[Expand]CodeRush Classic
[Expand]Cross-Platform Core Libraries
[Expand]Tools and Utilities
 End-User Documentation
View this topic on docs.devexpress.com (Learn more)

Conventions and Attributes

The MVVM Framework processes your application code and interprets specific code snippets in its own way. For instance, a property can be perceived as bindable if its syntax is correct. These syntax rules are called conventions. Conventions allow you to avoid writing extra code, since you know that the Framework will "understand" what you expect from it and automatically generate everything needed. This document gathers all MVVM Framework conventions that you need to be aware of when building an MVVM application.

Expanded Bindable Properties

All public auto-implemented virtual properties are treated as bindable.

To suppress bindable property generation for such properties, use the Bindable attribute as follows.

Properties with a backing field are ignored by the Framework. You can explicitly mark such properties with the BindableProperty attribute to still be able to use them for data binding.

Expanded Property Dependencies

Properties can change their values as the application runs. To keep track of these changes and respond to them, declare property dependencies. A property dependency is a method that is automatically executed when its related property changes or is about to be changed. To implement this behavior, the method must be called On<Related_Property_Name>Changing or On<Related_Property_Name>Changed.

The On...Changed and On..Changing methods can also have one argument. In this case, the argument will receive an old or new property value respectively.

The BindableProperty attribute allows you to use methods with different names as well.

Expanded Commands

All public void methods with zero or one parameter, declared in POCO ViewModels, are treated as Commands.

Methods whose names end with ...Command raise an exception. You can force the Framework to treat such methods as valid commands by marking them with the Command attribute and setting a proper name through the Name parameter.

For each command method, the Framework generates a corresponding backing property. This property is by default, named after the related method plus the "Command" suffix. You can reserve another name for this auto-generated backing property by using the Name parameter of the Command attribute.

Commands can be accompanied by CanExecute clauses - boolean methods that allow their related commands to be executed only if true is returned. Such methods must be called Can<Related_Command_Name>.

CanExecute methods with other names can still be bound to commands by using the CanExecuteMethodName parameter of the Command attribute.

CanExecute clauses are first checked when the command has just been bound to its target (to get the target's initial state). Later on, this criteria is recalculated each time the command's target is notified by the CanExecuteChanged event about command state changes. This event is declared at the underlying command-object level. To send such notification from the ViewModel level, call the RaiseCanExecuteChanged extension method as follows.

Expanded Services

To resolve Services, the Framework overrides virtual properties of an interface type. These properties' names must end with ...Service.

You can also explicitly mark service properties with other names by using the ServiceProperty attribute.

When the Framework overrides a service property, it generates the corresponding GetService<> extension method call. The ServiceProperty attribute allows you to specify additional parameters for this method (e.g., a service key).

Is this topic helpful?​​​​​​​