ViewModel multiple ways to handle view-related events (non-technical stickers, learning summaries only)

As we all know, in the UWP, Microsoft provides us with a new way of binding: X:bind, which is based on compile-time binding. In terms of performance, the runtime bindings binding is somewhat inferior to it compared to it. So for certain data that doesn't need to be changed, we have every reason to use x:bind for binding. (Of course, if you don't care about program performance, there's no need to look down!) ）

As Friends of MVVM know, we often encounter a situation where we need to bind a control to a command in a ViewModel, but this control does not have a command property? There are a lot of general solutions, and I'll give you a general list of some common solutions:

1, Eventtocommand ( more conventional )

Using event triggers to correlate is the most general and common solution. With blend, we can see that Microsoft has provided us with 10 different behaviors to meet our development needs. As for how to use this here is no longer detailed, interested friends can take a look at the article I wrote earlier: implement their own MVVM design pattern in the UWP . There is an introduction to this, which shows only 10 of these behaviors.

2. Message mechanism ( more flexible ):

If you've already used mvvmlight in your project, you'll have one more option, which is the set of messaging mechanisms that he has encapsulated for you (and you can, of course, implement it yourself). You can ensure that the control handles the right thing in the ViewModel in the appropriate event by sending a message and registering a message. This section how to use can refer to the blog Garden @ upstairs that Sorghum wrote a few about how to use mvvmlight articles, there are related to the introduction, quite suitable for new entry friends. Only the corresponding class members are listed here:

3, X:bind ( more simple ):

The native X:bind can also be used to register the event with the corresponding ViewModel. We've already got a rough idea of the benefits of using it, so I'm going to show you how to use it. I'll show you how to register the TextBlock tapped event in Mainviewmodel:

First we need to register the event in ViewModel, the code is very simple, and vs for our custom generated code exactly, you can simply cut vs for your auto-generated event function into the corresponding view. However, it is important to note that we need to set the access modifier of this function to public, otherwise view is inaccessible. The sample code looks like this:

Second, we need to associate the TextBlock tapped event with the events registered in ViewModel, and we'll try a regular binding:

<Text= "click Me"  Tapped= "{x:bind textblock_tapped} " />

Perhaps you write that this has started debugging, but the result may not have met your expectations, VS will give you an error: invalid binding path "textblock_tapped": The property cannot be found on type "MainPage" Textblock_ Tapped ".

Don't panic when you encounter an error, I believe you can read this error message to your solution. Yes, you need to set the corresponding data context in the corresponding MainPage.cs to tell the compiler that when you compile, you bind the corresponding function in the context of the data I specify. Therefore, we assign the relevant data context in the corresponding CS:

   Public Sealed Partial class Mainpage:page    {        publicget;}          Public MainPage ()        {            this. InitializeComponent ();              This  as Mainviewmodel;        }    }

The bindings are then modified in the corresponding XAML:

<Text= "click Me"  Tapped= "{x:bind VM. textblock_tapped}"/>

Writing here, you have successfully registered the event of a control in a view in ViewModel so that you can handle the corresponding thing in the ViewModel. About X:bind More introduction can refer to Blog Park, a blogger @e careless blog.

4. Custom command attributes ( with forcing ):

By customizing the dependency property to add the Command property to the control, I have to say that this implementation is the most pressing. To be honest, I didn't have to use custom dependency properties to solve my problem when I was writing code. Because sometimes I write it will encounter some inexplicable problems, ah, only blame me for not fine, the technology is temporarily looking into mo. Do not ask me how to write, I will not, slag A, look at you big God forgive me!

5. Summary:

In the actual development, we encounter problems will always emerge, the above several solutions are not discriminating ears, they have pros and cons, I think the award of fish than to give people to fishing, the right is the best. Therefore, the above 4 methods in my opinion, there is no comparable, whether complex or simple, as long as it can improvise, specific analysis of the situation is good!

ViewModel multiple ways to handle view-related events (non-technical stickers, learning summaries only)