Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In this tutorial INotifyPropertyChanged is in Model - not in ViewModel.
Is it correct and acceptable? What are standards ?
INotifyPropertyChanged is just an interface that provides functionality, it's not MVVM specific in any way. Classes generated by Linq to SQL or the like also usually implement it for example.
It is correct! You should raise PropertyChanged where you change the property (so in the model in your case). In other cases it might be in the view model but it can really be anywhere.
I think the confusion starts because the properties in the view model must raise the PropertyChanged event to update the UI. That does however not mean that the PropertyChanged event must have its origin in the view model.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm a beginner with wpf app building and entity framework.
I'm building my first wpf app, I found out I should have replaced my auto-generated ICollection with ObservableCollection.
The problem is that I already did most of my code so far but am having some issues with INotifyPropertyChanged. I see all the codes about INotifyPropertyChanged use ObservableCollection.
Is it bad if I go to my auto-generated code now and replace the ICollection with ObservableCollection? Will it mess up my app?
ObservableCollection is only useful if you want to add items to a collection at some point, and have a UI control automatically update to display the added / deleted items. ObservableCollection also has potential threading issues - any change to the collection must be done on the same thread as it was created on.
It has nothing to do with reflecting changes to properties of individual elements within the collection - that is what INotifyPropertyChanged is for.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I need load data from database in Prism application and I don't know when.
Should I load data in constructor of view model ?
When is right time to load data in Prism ?
Should I load data in constructor of view model ?
If you use the ViewModelLocator avoid loading data in the constructor to not block the ui. If you create the view model yourself (i.e. somewhere in a background task), nothing's wrong with loading data in the constructor. In fact, I'd prefer that because you always have an initialized instance.
When is right time to load data in Prism ?
The above being said, the best bet is to implement INavigationAware and load your data in OnNavigatedTo (asynchronously, of course).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I don't currently have an example for my question. I would just like to get some insight of the following : When should one use one or two way data binding in XAML ?
Thank you in advance for the time you take to answer this !
In summary: use OneWay if the property is readonly, use TowWay if you want to change it from your view.
TwoWay updates the target property or the property whenever either the target property or the source property changes.
OneWay updates the target property only when the source property changes.
REF：Binding.Mode Property. and BindingMode Enumeration
Use OneWay if you only want to update the view from your model.
TwoWay also updates the model if you change the view. e.g. a TextBox. So you should use it when you want that your view can affect the model.
MSDN-Page BindingMode
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is it common to store "non-model" classes (maybe helper classes) that I don't wanna use in a ViewModel inside Model directory in MVVM project?
For example:
Models\SongModel
Models\ID3TagReader
ViewModels\SongViewModel
If no, how should I encapsulate these classes?
In this design, the views know of the ViewModel and bind to its data, to be able to reflect any changes in it. The ViewModel has no reference to the views—it holds only a reference to the model.
For the views, the ViewModel acts both as a façade to the model, but also as a way to share state between views (selectedContacts in the example). In addition, the ViewModel often exposes commands that the views can bind to and trigger.
refer to the link..
http://blogs.msdn.com/b/ivo_manolov/archive/2012/03/17/10284665.aspx
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I know my question is subjective and context dependent, but being a beginner to MVVM, I came to know that generally one of the MVVM class is made singleton. Can anybody please tell me if I have Model, ViewModel and View class, generally people prefer which class as singleton and why is it so?
Technically, the Application class is really the only "required singleton" in a WPF application, and that's mainly because WPF will create it for you.
Otherwise, I typically avoid singletons in my WPF applications completely - there is no reason to introduce them.