WPF MVVM - using model in view model class - wpf

I would like to know what is correct using of model class in in view model. As MVVM I use Caliburn Micro.
First alternative.
Model class:
public class CurrentUser : IDataErrorInfo
{
public string Nick { get; set; }
public string Password { get; set; }
//...
}
Using model in view model class:
[Export(typeof(ILogOnViewModel))]
public class LogOnViewModel : Screen
{
public CurrentUser CurrentUser { get; set; }
//bind on control in view
public string CurrentNick
{
get { return CurrentUser.Nick; }
set
{
CurrentUser.Nick = value;
NotifyOfPropertyChange(() => CurrentNick);
}
}
//bind on control in view
public string CurrentPassword
{
get { return CurrentUser.Password; }
set
{
CurrentUser.Password = value;
NotifyOfPropertyChange(() => CurrentPassword);
}
}
}
Second alternative:
Model class:
public class CurrentUser : IDataErrorInfo, INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
private void NotifyPropertyChanged(String info)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(info));
}
}
public string Nick
{
get { return _nick; }
set
{
_nick = value;
NotifyPropertyChanged("Nick");
}
}
public string Password
{
get { return _password; }
set
{
_password = value;
NotifyPropertyChanged("Password");
}
}
//...
}
Using model class in view model class:
[Export(typeof(ILogOnViewModel))]
public class LogOnViewModel : Screen
{
//bind on UI control
public CurrentUser CurrentUser { get; set; }
}

The first alternative would be better, since it encapsulates your model better from the View.
But you should implement IDataErrorInfo and INotifyPropertyChanged on the ViewModel, since the ViewModel should be the object that notifies your user interface of changes and errors.

I would prefer the first approach. There are a few reasons why:
A Model should never be accessible to View.
In theory, a ViewModel wraps/facades all properties required to be bound to View from Model. It adds any additional properties, collections and commands required to facilitate View's functionality and while preventing putting code in code behind.
IDataErrorInfo and INotifyPropertyChanged facilitate View not ViewModel. And since View only communicates with ViewModel, they should be inside ViewModel.

I would use the second approach. If you are looking for sample applications that use the second approach then you might find the WPF Application Framework (WAF) project interesting.

I'd recommend starting off with the second approach. It could save you from typing out a lot of repetitive bridging properties. If you encounter a property that needs to be wrapped on the View Model, then do so for that property then update the View's binding(s). Both your Model and View Model can implement IDataErrorInfo and INotifyPropertyChanged. The latter is quite useful when some logic in your Model changes a property since it will then be propagated to the View. Implementing those interfaces via base classes, you could have both a ModelBase and a ViewModelBase abstract classes, where the latter derives from the former.

Related

Correct way to update property in ViewModel from Model

I'm fairly novice with WPF. It's my understanding that data changes in the model, and it should notify the viewmodel, and the view will bind to properties and things alike in the viewmodel. Is this correct? If so, I've been reading that the model should implement INotifyPropertyChanged, and look something like this
public class LoginModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public void NotifyPropertyChanged(string propName)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propName));
}
public bool Authenticated { get; set; }
}
and in my ViewModel, I have a property "AuthResult", that should get the update from the Model property "Authenticated"
public partial class view1 : UserControl, INotifyPropertyChanged{
public bool AuthResult
{
get
{
return _authVal;
}
set
{
_authVal = value;
NotifyPropertyChanged("AuthResult");
}
}
public event PropertyChangedEventHandler PropertyChanged;
public void NotifyPropertyChanged(string propName)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propName));
}
}
I know this current implementation is incorrect. I've found that I should be subscribing to the PropertyChanged notification from my model like so:
LoginModel.PropertyChanged += new System.ComponentModel.PropertyChangedEventHandler(LoginModel_PropertyChanged);
void LoginModel_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
if(e.PropertyName == "Authenticated")
{
//do something
}
}
I don't see where the "AuthResult" property should be updated. Would I do something in the If statement like AuthResult = _model.Authenticated;?
EDITED:
and in my constructor?
LoginModel _model;
public view1(LoginModel model)
{
_model = model;
InitializeComponent();
}
If the model implements the INotifyPropertyChanged interface you can bind directly to it from the view:
<Button Content="Button" IsEnabled="{Binding Authenticated}" />
Note that the LoginModel class must raise the PropertyChanged event whenever the Authenticated property is set to a new value.
You could also expose the entire model entity through the view model class:
public class ViewModel
{
public ViewModel(LoginModel model)
{
Model = model;
}
public LoginModel Model { get; }
}
...and bind to it like this:
<Button Content="Button" IsEnabled="{Binding Model.Authenticated}" />
It is still the model class that must implement the INotifyPropertyChanged interface and raise change notifications.
Another option is for the view model to wrap any property of the model class that you want to be able to bind to from the view. Then you bind to a property of the view model class that in turn wraps a property of the model class something like this:
public class ViewModel
{
private readonly LoginModel _model;
public ViewModel(LoginModel model)
{
_model = model;
}
public bool AuthResult
{
get
{
return _model.Authenticated;
}
set
{
_model.Authenticated = value;
NotifyPropertyChanged("AuthResult");
}
}
}
<Button Content="Button" IsEnabled="{Binding AuthResult}" />
The benefit of using this latter approach is that view has no dependency upon the model class. It binds to the view model class only and this is how the MVVM design pattern typically is meant to be implemented.
But if you do bind to a (wrapper) property of the view model and want the view to be updated whenever a property of the model class is set, the model has to notify the view model that it has changed one way or another, i.e. it has to raise some kind of event or similar. And this typically means implementing the INotifyPropertyChanged interface. The view model can then subscribe to the PropertyChanged event of the model and raise its own PropertyChanged event for the data bound property whenever the model is updated, e.g.:
public class ViewModel
{
private readonly LoginModel _model;
public ViewModel(LoginModel model)
{
if (model == null)
throw new ArgumentNullException("model");
_model = model;
_model.PropertyChanged += OnModelChanged;
}
private void OnModelChanged(object sender, PropertyChangedEventArgs e)
{
if (e.PropertyName == "Authenticated")
NotifyPropertyChanged("AuthResult");
}
public bool AuthResult
{
get
{
return _model.Authenticated;
}
set
{
_model.Authenticated = value;
NotifyPropertyChanged("AuthResult");
}
}
}
Just use Model as member in the ViewModel
public class ViewModel
{
private Model _myModel;
public Model MyModel
{
get { return _myModel; }
set
{
if (Equals(_myModel, value)) return;
_myModel = value;
NotifyPropertyChanged(nameof(MyModel));
}
}
}
Then in xaml you can bind properties of Model
<CheckBox IsChecked="{Binding MyModel.Authenticated}" />
With this approach your ViewModel will be "build" around your Model.
In case you don't want that models implement INotifyPropertyChanged than create a "Facade" class of model in use it in same way as previous example.
public class ModelFacade : INotifyPropertyChanged
{
private Model _myModel;
public bool Authenticated
{
get { return _myModel.Authenticated; }
set
{
_myModel.Authenticated = value;
NotifyPropertyChanged(nameof(Authenticated));
}
}
}
public class ViewModel
{
private ModelFacade _myModel;
public ModelFacade MyModel
{
get { return _myModel; }
set
{
if (Equals(_myModel, value)) return;
_myModel = value;
NotifyPropertyChanged(nameof(MyModel));
}
}
}

For MVVM, what is the best practice for viewmodel to export the property in model to view?

As a new one to WPF, I start my MVVM travel recently. I can understand the orginal intension about why we need MVVM, but some of the implementation detail still confuse me a lot.
Here is one of my questions:
How should I export the property in model to View via ViewModel
I can show some of my idea here, so please share your view with me.
Here is one of my implementation:
class MyModel : INotifyPropertyChanged
{
private String _name;
public String Name
{
get { return _name; }
set
{
if (_name != value)
{
_name = value;
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs("Name"));
}
}
}
}
public event PropertyChangedEventHandler PropertyChanged;
}
class MyViewModel
{
private MyModel _model;
public MyModel Model
{
get { return _model; }
set { _model = value; }
}
}
I think the problem for this is we do not decouple the view from model. And the view need to know every detail about the model implementation to accomplish the Binding process. And exporting the propert in Model directly to view from ViewModel cannot be treat as a good design in my opinion.
So I hope you can share your experience on the design about this topic.
BTW,
If we export many object, such as, a List of MyModel object to view from viewmodel, how can I implement this to decouple the view from model?
Not your Model, but your ViewModel shall implement INotifyPropertyChanged. Then you can use Binding in the View to get the Data from the ViewModel.
In your View / XAML you have statements like
... Content="{Binding myViewModelProperty}" ...
depending on what you are binding.
myViewModelProperty has to be a public property in your ViewModel
public string myViewModelProperty { get; set; }
Do not forget to call RaiseNotifyPropertyChanged (or what your handler is called) in the setter to get updates in the View.
private string myViewModelField;
public string myViewModelProperty
{
get
{
return myViewModelField;
}
set
{
myViewModelField = value;
RaiseNotifyPropertyChanged(() => myViewModelProperty);
}
}
** Update **
Lists are typically "exported" via ObservableCollection<Type>.
Ideally Type is some ViewModel here, created with data from the model to
be shown in your View. You can imagine the ViewModel as Adapter between
your model and your view.
This is not a strict rule, but in my case I prefer to implement INotifyPropertyChanged in the ViewModels and to leave the Models as simple POCOs.
It can be annoying to "repeat" the properties of the Model in the ViewModel, but :
Generally you don't need to expose all the properties to the View.
It allows you to add additional code like user input validation in your VM and keep your Model "clean".
So in your example it would be:
class MyModel
{
public String Name
{
get;
set;
}
}
class MyViewModel : ViewModelBase //let's say you have this base class in your framework
{
private MyModel model;
public MyViewModel(MyModel model)
{
this.model = model;
}
public string Name
{
get
{
return this.model.Name;
}
set
{
if(IsValidInput(value)
{
this.model.Name = value;
this.RaisePropertyChanged("Name"); // the ViewModelBase base class provide this helper.
}
}
}
}
About your second question, ObservableCollection is usually a nice way to expose a collection of Models to the view:
class ContactListViewModel
{
public ObservableCollection<MyModel> Contacts { get; private set;}
}
You can simply bind your property on view wiuth Model.Name

Silverlight entity-level validation with MVVM

I try to adopt entity-level validation (attributes validation on properties on entities) by create ViewModel that expose that Entity.
public class MyViewModel
{
public MyEntity MyEntity { get; set; }
}
I set binding in xaml to, this xaml page set its DataContext to instance of MyViewModel
TextBlock Text="{Binding MyEntity.MyProperty}"
When I load MyEntity from database and set it to MyViewModel, nothing happen. I also call NotifyPropertyChanged("MyEntity"); and it still nothing happen.
I try again by create MyProperty in MyViewModel
public class MyViewModel
{
private MyEntity MyEntity { get; set; }
public string MyProperty
{
get { return this.MyEntity.MyProperty; }
set { this.MyEntity.MyProperty = value; }
}
}
And changed xaml to bind to MyProperty. This time when I call NotifyPropertyChanged("MyProperty "); View get update correctly, when I input incorrect data, it has ValidationErrors at MyEntity but View don't raise that error (not show red border)
I want to know how can I get entity-level validation working with MVVM.
Hi
you must change the definition of ViewModel such as
public class MyViewModel:IDataErrorInfo
{
}
and implement interface.
this force View to show red border on error.
wish to help.

How to save data from a DetailView bound to a ViewModel if the repository is a no-go in a viewmodel?

we mvvm lovers all know Josh Smith mvvm sample and how he has saved the customer in the detail customer view by injecting the repository object into the customerViewModel`s constructor.
But a viewmodel should not know about repositories. Its just a model of a view nothing must being aware of persistence etc...
How can I register my Action delegate SaveDocumentDelegate on the DocumentViewModel if its set in the code-behind? Actually I should subscribe the delegate in my DocumentController but how can I instantiate the DocumentView in my DocumentController and set it as Datacontext not doing that in code-behind. Only thing that came to my mind is using a contentcontrol in the window and bind it to the type of the viewModel and datatemplate it with the Document UserControl like this:
<UserControl.Resources>
<DataTemplate DataType="{x:Type ViewModel:DocumentViewModel}">
<View:DocumentDetailView/>
</DataTemplate>
</UserControl.Resources>
<ContentControl Content="{Binding MyDocumentViewModel}" />
But I do not want to use a control to solve my architectural problems...
xaml:(view first approach)
public partial class DocumentDetailView : UserControl
{
public DocumentDetailView()
{
InitializeComponent();
this.DataContext = new DocumentViewModel(new Document());
}
}
DocumentViewModel:
public class DocumentViewModel : ViewModelBase
{
private Document _document;
private RelayCommand _saveDocumentCommand;
private Action<Document> SaveDocumentDelegate;
public DocumentViewModel(Document document)
{
_document = document;
}
public RelayCommand SaveDocumentCommand
{
get { return _saveDocumentCommand ?? (_saveDocumentCommand = new RelayCommand(() => SaveDocument())); }
}
private void SaveDocument()
{
SaveDocumentDelegate(_document);
}
public int Id
{
get { return _document.Id; }
set
{
if (_document.Id == value)
return;
_document.Id = value;
this.RaisePropertyChanged("Id");
}
}
public string Name
{
get { return _document.Name; }
set
{
if (_document.Name == value)
return;
_document.Name = value;
this.RaisePropertyChanged("Name");
}
}
public string Tags
{
get { return _document.Tags; }
set
{
if (_document.Tags == value)
return;
_document.Tags = value;
this.RaisePropertyChanged("Tags");
}
}
}
UPDATE:
public class DocumentController
{
public DocumentController()
{
var win2 = new Window2();
var doc = new DocumentViewModel(new DocumentPage());
doc.AddDocumentDelegate += new Action<Document>(OnAddDocument);
win2.DataContext = doc;
wind2.ShowDialog();
}
private void OnAddDocument(Document doc)
{
_repository.AddDocument(doc);
}
}
What do you think about that idea?
But a viewmodel should not know about
repositories. Its just a model of a
view nothing must being aware of
persistence etc...
The viewmodel connects the model and view together; it is exactly what controls persistence, though it does not handle persistence.
We decouple this from other concern by using services.
One way to avoid adding persistence concerns to the viewmodel is by abstracting those concerns into repository interfaces, so that we can inject it as a dependency. In this way we can delegate persistence work in the viewmodel, usually in response to the user's interaction with the view.

Broken binding with Prism, Silverlight and ViewFirst approach

The problem we are having is that we cannot get binding to work in our
prism silverlight application when using the view-model first
approach. The view first approach work fine. We have gone over the
official documentation and various web sites, but have still not
resolved the issue. Below is the code for both the view-model first,
and the view first approach. Are we missing something? Read about it on my blog http://silvercasts.blogspot.com
View-Model first approach:
Bootstrapper:
internal void RegisterLoginRegionAndView()
{
IRegionManager regionManager = Container.Resolve<IRegionManager>();
regionManager.RegisterViewWithRegion(ShellRegionNames.MainRegion,
() => Container.Resolve<IViewModel>().View);
}
ViewModel:
public ViewModel(IView view)
{
View = view;
View.SetModel(this);
User = new User();
User.Username = "TestUser";
}
ViewModel Interface:
public interface IViewModel
{
IView View { get; set; }
}
View Interface:
public interface IView
{
void SetModel(IViewModel model);
}
View Xaml:
<TextBox x:Name="Username" TextWrapping="Wrap" Text="{Binding User.Username}" />
View Code Behind:
public void SetModel(IViewModel viewModel)
{
this.DataContext = viewModel;
}
View first approach
Bootstrapper:
regionManager.RegisterViewWithRegion(ShellRegionNames.MainRegion, typeof(IView));
ViewModel:
public ViewModel()
{
User = new User();
User.Username = "TestUser";
}
View Code Behind:
public View(IViewModel viewModel)
{
InitializeComponent();
this.DataContext = viewModel;
}
Your implementation of SetModel on your view needs to be as follows:
public void MyUserControl : UserControl, IView
{
//...
public void SetModel(IViewModel vm)
{
this.DataContext = vm;
}
}
If that's not there, it needs to be (you haven't posted your implementation of SetModel, but this would be the source of the issue in this case).
If this is not the issue, it's likely because your ViewModel does not implement INotifyPropertyChanged. I usually use a base ViewModel that does this:
public class ViewModelBase : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public void OnPropertyChanged(string propertyName)
{
if(PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
}
And then all of my ViewModels derive from that:
public class MyViewModel : ViewModelBase
{
private User _user;
public User User
{
get { return _user; }
set
{
_user = value;
OnPropertyChanged("User");
}
}
}
Note: in your case the "User" object should probably also be a ViewModel and also raise OnPropertyChanged for the Username property.
Hope this helps.
The obvious difference to me is that you set the DataContext in the "view first" approach, but not in the "view model first" approach. I'm not sure if Prism sets the DataContext for you (I'd guess that you're assuming that it does) but try setting the DataContext manually to see if this is the problem. In your ViewModel constructor you call View.SetModel(this) - does that call set the DataContext?
The problem was that I was using the SetModel method before the data object was instanced. Moving it like this:
public ViewModel(IView view)
{
View = view;
User = new User();
User.Username = "TestUser";
View.SetModel(this);
}
solved the problem.

Resources