OTHER RELATED ARTICLES:
- Getting Started with DevExpress MVVM Framework. Commands and View Models.
- DevExpress MVVM Framework. Introduction to Services, DXMessageBoxService and DialogService.
- DevExpress MVVM Framework. Interaction of ViewModels. IDocumentManagerService.
- THIS POST: DevExpress MVVM Framework. Introduction to POCO ViewModels.
- DevExpress MVVM Framework. Interaction of ViewModels. Messenger.
- DevExpress MVVM Framework. Using Scaffolding Wizards for building Views.
- DevExpress MVVM Framework. Data validation. Implementing IDataErrorInfo.
- DevExpress MVVM Framework. Using DataAnnotation attributes and DevExpress Fluent API.
- DevExpress MVVM Framework. Behaviors.
- DevExpress MVVM Framework. TaskbarButtonService, ApplicationJumpListService and NotificationService.
- DevExpress MVVM Framework. Asynchronous Commands.
- 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; }
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:
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.
- For a ViewModel with a public parameterless constructor, the following approach is simple and fast:
ViewModelSource.Create<LoginViewModel>();
- 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"
});
- 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).
Free DevExpress Products - Get Your Copy Today
The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the
DevExpress Support Center at your convenience. We'll be happy to follow-up.