User Interactions in MVVM - Overview

One of the common questions regarding MVVM is, how to interact with the user. For example: how to present the user a message, how to open a window and the like.

Many programmers come to this point, and they are giving up the principles of MVVM. Sometimes, they ask: Why not open a MessageBox from the ViewModel? Why do we need beating about the bush,but not to write the code simple and short MessageBox.Show ("Some message")?

With Dialogs the problem is more complicated. Without MVVM, we would write code like this:

var dialogViewModel = new dialogViewModel();
var dialogView = new dialogView()
{
    DataContext = dialogViewModel
};
dialogView.Show();

But according to the principles of MVVM, the ViewModel is forbidden to be aware to MyDialogView, so what will he do with MyDialogViewModel? And what actually forbidden to be aware ViewModel to View? And in this regard, many people wonder: Why not write the simple code above?

So first, Let's mention one of the goals of MVVM: Testability. See here for more info about this point: Writing a Testable Presentation Layer with MVVM

That is why in ViewModel should not write something like MessageBox.Show or MyView.Show, because it blocks the possibility of writing tests.

So what to do? An exhaustive description of the solutions, you can read in this recommended article: User interactions patterns writen by Prism team.

But i think that Prism's paradigm is too complicated. If you have 100 MessageBox'es, you should create 100 InteractionRequest's and 100 InteractionRequestTrigger and they are all doing exactly the same work, so why duplicate the code again and again?!

And on the sidewalk across the street, if we are looking on MVVMLight - The other common library, it's doesn't includes any solution for interactivity. It's include only IDialogService interface, but not any implementation of this interface.

In the coming posts, we will implement simple and convenient patterns for interactions, alert, prompt, popups and more.

Binding ScheduleView to Database - Conclusion

In this series, we saw how to work with ScheduleView control and how to binding to database. The modern design patterns were strictly kept, and The results are very elegant code, readable, and easily implementable.

This series is modular. You can read and implement each part separately, but I recommend to read this in order, from part 1 to part 8.

For each part, I created specific branch of the source code, but you can download the 'master' branch if you want to see the whole story.

https://github.com/YehudahA/ScheduleViewPractices/tree/master


I'll be glad to get comments, corrections or questions.

1. QuickStart	The shortest way: using of inheritance from the ready class 'Appointment'
2. Considerations	When is better to custom implement the 'IAppointment' interface.
3. Implement custom Appointment	How to implement the IAppointment interface.
4. Categorize	How to associate Appointment to category.
5. Categories editor	Let the user Create/Change/Delete categories
6. Resources	How to allocate resources to the Appointment.
7. Recurrence rule	Configure repeating appointments.
8. Time marker	Assign a time marker to Appointment

Binding ScheduleView to Database part 8: Time Markers

OK guys, we implemented already most of the Appointment functionality, and we have just a little job for completing: Time markers.

ScheduleView provides us a time markers support. we can assign a time marker to each one of our appointments, thus making them easily distinguishable.

Usually, the end user should select from a closed list, and he should not have to edit the list. Therefore, unlike categories. Therefore, Usually we do not need to store the TimeMarker options in the database, and we can set it in the code.

However, if you want, you can also create a Model for TimeMarker, and manage them in the database, as we did with categories. But below, we will implement the easy way.

Binding ScheduleView to Database part 7: Recurrence

ScheduleView provides the functionality to configure repeating appointments. The user has the ability to apply recurring scheduling patterns such as daily, weekly, monthly or set a range of recurrence from date to date. If you have a daily task, for example: call mom, you can create an appointment and set his RecurrenceRule.

It is recommended to read Telerik's documentation, they explains very clearly, but they explanation only how to work with in-memory data, while in the real-world we want working with database.

Relative to previous articles, this article is a little complicated, because it covers a lot of objects, and requires an understanding of the internal behavior of the machine. I worked hard to decipher the behavior required, including code-review of the Telerik's source code [of course: with Telerik JustDecompile].
But in the end, I got a very good result, readable and elegant code, and here it is.

The source code, is available on my GitHub reporitory, and i recommend to see it. Here, I'm focusing only the essentials, so as not to burden the reader.

Binding ScheduleView to Database part 6: Resources

The RadScheduleView allows you to define custom resources that can be assigned to the appointments. For example: you can assigned appointment to specific man or specific location.

You can read about Resources in this article writen by Telerik team. The article is very simple, and I recommend to read it before this post. 

But as you can see, the Telerik's article [and other Telerik's samples] defines the resources as in-memory collection, while in the real world we want store the resources in the database.

In this post we will see how to do it, simply and easily.

Binding ScheduleView to Database part 5: Categories editor

In the previous post we saw how to associate an appointment to category. What about categories editing? How the user can edit the categories?

The solution is very simple: GridView with two columns, one is bound to DisplayName property, and the second is custom column with ColorPicker control, and it bound to CategoryBrush property.

Below is the code of the editor View. The source code is available on my GitHub repository, including the ViewModel, Mvvm DialogService and more.

Binding ScheduleView to Database part 4: Categories

Let's see how to work with categories and database.

The source code for this post, is available on GitHub.

1. CategoryModel class

First, we need define a class, which it is derived from ICategory interface.

public class CategoryModel : BindableBase, ICategory

I use the Model suffix, to avoid confusing with Telerik's Category class.
Usually, we want also give to user the ability of Edit the categories, therefore our class must be derived from INotifyPropertyChanged or BidnableBase [ViewModelBase if you use MVVMLight].