Lecture thumbnail 0:00 / 0:00 So sometimes you need to wire your objects to user interfaces, and in that case you might want additional
functionality to what the objects provide.
So for example, you want property change notifications, or you want, let’s say, validation of your
property.
So the question is how can you do it while sticking to the principle of separation of concerns?
Now let’s suppose you have some domain object.
Let’s say you have a person.
So a person is just an element.
It’s a model from the database.
It might have certain members.
I’m going to have public fields here, so you might have first name and last name, for example.
So these would be attributes of, let’s say, some data table in a database.
Now, one thing you could do if you want to bind this to the user interface is you could start implementing
those interfaces for, let’s say, property change notification.
So you would go and you would implement something like notify property change, for example, and you
would also implement maybe data error info and other things.
But the problem with this approach is that you typically want to separate concerns.
So if you want change notification, you need to make it happen elsewhere.
You don’t necessarily want it to happen right inside your model.
So we can leave the model as is.
We can have a person here.
We can also have methods related to person here, for example.
But when it comes to showing it in the user interface, you build an additional component which will
actually take care of things like change notifications, for example.
And that component is typically called a view model.
So this is all part of something called mvvm, which is a paradigm that, for example, the WPF framework
uses Mvvm.
So what is this all about?
Well, it has three things in it.
It has a model.
So the model would be, let’s say this class person.
So this class could have been generated from a database, for example, or some sort of script or something.
You don’t really want to add validation and change notification right inside person.
You might want to keep those things separate because they only relate to the user interface.
So then we have the second part, which is the View.
So the view is typically the UI that actually shows whatever it is that you want to show.
So a view, for example, could be, let’s say a Xaml page, which is bound to a view model.
So the view model is the representation, the kind of the data that you want to show on the user interface.
So the view model is exactly the location where you would add change notifications on, let’s say first
name and last name, but you could also add additional functionality.
So for example, if you want an editor which lets you edit the full name at the same time, both first
name and last name, then this is where it would typically go.
So let’s take a look at how we can build a ViewModel for a person.
So you would have a class called the Person View model.
In actual fact, I would sometimes call it a person view without the model part because we know that
the Xaml or whatever is in fact The View.
So here we would take the word view to mean like a view into a person, but let’s have it as person
view model.
So person view model would be typically a proxy of the person itself.
So it would have a constructor which would take the person and it would simply store the person internally
and then you would replicate the fields as properties, but you would replicate them in such a way that
they also provide change, notification and whatever else that you actually need.
So here you could do.
I notify property change, for example.
You could generate all the relevant invocations here.
These are automatically generated by the ID, And then when it comes to implementing first name and
last name, for example, then you would just go ahead and you would have it here.
So you would have public string firstname and the getter would simply get the information from person
dot first name.
But the setter is more interesting because this is where we have that additional concern of change notification.
So here we say if person dot first name is equal to value, then return, then person dot first name
equals value.
And then we call on property change like so.
And similarly, you would implement last name.
So you would go ahead and you would implement last name in a similar fashion.
And this would allow you to basically have this wonderful proxy that you could actually use in the UI.
So you would initialize it with a person that is actually stored somewhere in the sort of data storage
layer of your application.
And then you would go ahead and you would manipulate these properties.
So you would take each of these properties and you could bind them to a user interface element, like
a text box, for example.
And when the person edits the text box, then we invoke the setter and do whatever notifications are
required.
And once again, you know, this is when you change the view behind the scenes.
When you change the ViewModel properties, then the UI will be correspondingly updated.
So.
So this is how you would do this.
And so far, what we have is we have a proxy because we’re essentially replicating the interface almost
once again.
Notice the constructor here takes a person, but then you are replicating the interface.
We can sort of take it a bit further and move it into decorator territory.
Remember, decorator is a thing which kind of augments the set of functionality with additional members
which the underlying object, in this case this person does not.
So, for example, let’s suppose we decide we want to have a full name in addition to just the first
name and last name.
So you would have a property called full Name.
This could once again be bound to a text box, for example.
Now, the getter here would be different because you would take the first name and then put a space
and then do a last name.
But remember, some of these can be empty, so it might make sense to actually trim the entire string.
And then for the setter, well, the setter would be a bit more interesting.
First of all, it makes sense to do a null check.
So if the value is null, then we set both of the requisite properties to null.
So both the first name and the last name are going to be set to null, and then we just return from
here.
And then if that’s not the case, then we take a look at the full name.
We split it into the first and last names and we actually sort of get to get to assign those.
So we say var items equals value dot split like so.
And then if items length is less is greater than zero, then we assign the first item.
So first name equals items at zero.
And similarly, if items dot length is greater than one, so it’s two or more, then we say last name
equals items at position one.
Now, when you perform these assignments, notice we’re assigning the actual properties, not we’re
not saying person dot, we’re not assigning the fields, we’re assigning the actual properties.
And as a result of this, what happens is you basically cause change notifications if they are required.
So if items dot zero has changed first name, then you would end up in the setter right here.
And so it would compare the values and then do the change notification if it is indeed required.
So this is how you can go from a proxy to a decorator and get some of those additional properties.
And now if you have full name, you can bind it to, let’s say, a text box.
And then the expectation is that whenever a first name or last name changes in code, let’s say you
change it behind the scenes, then the text box will get updated.
Or will it?
This is an interesting question once again, because it might make sense to sort of duplicate this and
put, let’s say, full name here and do the same thing.
In actual fact, I think you need a name of and do the same thing in the other one.
So let’s copy this over and paste this in here.
So this is a more correct way of handling things because full name is in fact affected by both the first
name and the last name.
So this is how you set up something called a view model.
A view model is essentially just a representation of the data that you want to show with additional
functionality.
Like in this case, we have change notification, but you could also add validation.
You could add additional things, whatever it is that you wanted to do.
And you can also separate those so you can have a view model just for change notification.
And you can also have some sort of validation which once again wraps around person and does something
else, makes things a bit more complicated.
But it’s also a possibility if you want to strictly adhere to the single responsibility principle.
Play Play Play Play Play Play Play Play Stop Start Play Play information alert