I have a model called Events and a Model called Persons. Am I fine, when I include an ObservableCollection of the type Persons in the Event Model? Is this right MVVM? Do I need everywhere an NotifyPropertyChanged?
Sounds fine to me. Have both your Event model and Person model implement INotifyPropertyChanged.
The front end can then be notified when the ObservableCollection changes and also be notified when properties on the Event and Person models change.
Will you display in the Events view the list of persons? if that is true then you are correct, that is MVVVM, remember the ViewModels stands between your Models and your Views, and need to satisfy the data and functional requirements of your View.
Related
I have read that in MVVM the VM should know nothing about the view and view should not bind directly to the model, but should bind to the VM which forwards on properties from model and manipulates the model as required. So I guess the model classes do not need to implement INotifyProperty changed as this is handled by the view model.
This is all fine when there one of everything but I am not sure how to arrange things when there are parent child relationships. Say we have an Order object which has properties (customer name, address etc.) which are displayed on the order view. So an OrderView binds to an OrderViewModel which has a reference to an Order (model) object. Each Order object has a list of OrderItem (model) objects which has properties like item, quantity total etc.
Now the OrderView needs to display a list of OrderItems (say in a GridView) and so bind to a property called Items on the OrderView. What should the type of this property be? If it’s List then out view is binding directly to model object, which is against the principles I mentioned at the start and, our OrderItem object does implement INotifyPropertyChanged. Should the OrderItem be “wrapped” in some kind of VM object, and if so what should we call it – OrderItemViewModel? I’m not sure this is a good fit as is not the view model of an order item view – its just providing properties for the GridView to bind to, and that name conflicts with OrderItemViewModel class described below
Now lets say we have an OrderItemView which is a UserControl which is a child of the OrderView. Its role is to display the currently selected order item on the OrderView. Am I right is saying that It’s view model should be called OrderItemViewModel and it should have a reference to the currently selected order which is set by the OrderViewModel, so the OrderViewModel has knowledge of the OrderItem view model?
So I guess the model classes do not need to implement INotifyProperty changed as this is handled by the view model.
It depends on how you define a model. A model is typically a service of some kind that you may inject a view model with. Or a server-side domain object that contains business logic.
A type that you bind to in the view may be seen as a "child" view model. For example, if your OrderViewModel class exposes the following property:
public ObservableCollection<Order> Orders { get; }
..it is perfectly fine for the view to bind to properties of the Order class and for the latter to implement the INotifyPropertyChanged and any other client-related stuf. In this case Order is effectively a view model and not an actual model.
I have two classes:
ViewModelA
MainViewModel.
Both implement INotifyPropertyChanged interface.
MainViewModel holds an observable collection of ViewModelA objects. I need a change of a certain property "X" in any ViewModelA class to trigger a PropertyChangeNotification in property "Y" in MainViewModel.
Question 1:
What is the common practice to implement this?
Question 2: Is listening to CollectionChanged on the ObservableCollection and attaching/removing an event handler (that would check if the "X" property was changed and if yes would trigger the "Y" property change notification) a bad practice? If yes why?
I would implement my own event in ViewModelA, and subscribe it when creating a new ViewModelA in MainViewModel. The event will be called in ViewModelA, if some thing habbend.
Just to clarify the problem: you wish to callback to the parent view model when a property of a child view model (or in your particular case an element of a collection of child view models) changes.
In your particular case you want to to call the INotifyPropertyChanged event with some property on the main view model to update the UI.
Essentially, you are looking at some derivation of the Observer Design Pattern, whereby you somehow "listen" for changes on the child view model and the parent is notified. Two implementations of this pattern readily exist for you to consume:
Events: As somebody else has already answered in this question - you could create an event on the child view model, and subscribe to this event from the parent directly. Personally, I shy away from defining events on my view models where possible - for me a view model is a logical representation of the view, and having a public event on the view model interface seems to go against the grain.
Event Aggregator: Using an Event Aggregator (such as the one provided by PRISM) allows you to subscribe to messaged on the parent view model that are fired out of the child view model. The price you pay for not having to have a public event defined on your child view model is a dependency on an implementation of IEventAggregator. I like this approach as it separates out the concerns of the parent and child view models, and the interaction between them. One word of warning is that use of the event aggregator is open to abuse, and if you use it carelessly it can make it hard to track all the messages that are flying around your application.
Please, help me to understand one thing in the MVVM pattern:
For example, I need to display cities on a map.
In ViewModel I have ObservableCollection, that binded to a View ItemsSource.
ObservableCollection contains objects with type "City".
Must "City"-class be inherited from ObservableObject (I use MVVM Toolkit)? Or I should create a wrapper class, inherit it from ObservableObject, in ViewModel create new wrap-objects with data from "City"-objects and add them to the collection?
Thank you!
Assuming that your City class is in your model, and you actually need to know about changes to properties on the city object - then you should create a wrapper for it (i.e. CityViewModel). Your wrapper should listen to events that notify of any changes to the City class, and fire off the relevant Property Change notifications.
Model classes should be designed to fit with the model and should not change to suit your view - the point of having a ViewModel in the first place is to abstract your model from your view. The model should know nothing of the View.
If the properties of your City class dont change, or you dont care if they don change (and you are not a purist) then you could just expose it directly - without inheriting ObservableObject.
(Although I dont use MVVM toolkit, I cant see why in general you would need to inherit ObservableObject just because you are storing the City objects in an ObservableCollection).
The purist view however, is to wrap everything that you bind to and never expose anything from the model directly to the view.
ObservableCollection or ObservableObject has no relation with MVVM model. You can create a MVVM based application without ObservableCollection and ObservableObject (ObservableObject are used when you need to change the values of property of your class but if your application is readonly you dont even need it).
MVVM -
M-Model (business layer) , V-View (GUI), ViewModel- (Context of GUI).
When XAML works on binding. You must need a notification mechanism to notify GUI that something is changed. Now if a collection is changed means you added or removed an item from collection, you need to raise a notification which you dont need if you are working with ObservableCollection. Similarly, if your class City has a property Population which when changes need to notify GUI, that's why need to make an ObservableObject.
Hope it helps..
I need some help about MVVM pattern.
I created a ViewModel that expose data and commands to be displayed in a listview in a View named A.
This ViewModel is also used in a view named B. In this view, i just need to expose some properties and no commands but i had to create 2 more properties.
Is it better to create a more specific ViewModel for View B even if it concerns the same object?
I would suggest composition, have two view models which both have a property containing a view model that holds the common properties. The two view models should then only have their specific other properties and commands.
Difficult to answer. But i can tell you what we do for our application. We have one viewmodel, which is more or less view independant, it just functions as a wrapper for our business data and contains all the stuff that is used in almost all parts where this model is shown. Now for the view part, we have very specific viewmodels. Like a ProjectTreeViewModel or a SearchResultViewmodel, with the corresponding Item viewmodels for both of them. The Item viewmodel doesn't need to implement all the logic again, it just needs to agregate the general model view model.
To give a better analogy:
If you have a File, Drive and Folder model. You would create a FileViewModel, DriveViewModel and FolderViewModel. But only one ExplorerItemViewModel. This only needs to provide a property to expose the underlying view model. The rest is depending on your data templates.
Let's say I've got a View. It's DataContext is bound to a ViewModel and the ViewModel exposes a Model property.
Is it MVVMlike to bind fields in the View to properties in the Model (e.g. Binding Path=Model.FirstName)?
Should the Model implement INotifyPropertyChanged?
My team are using Prism and MVVM in WPF. A lot of the Prism examples bind indirectly to the Model. I personally have my doubts that this is the correct approach. I think stuff in the model should expose behaviour (not just at the property level) and should communicate important events by, er, events - that clients can subscribe to or not.
I think that by having domain/model objects implement INotifyPropertyChanged somehow says to the world that it's UI/UX aware and kind of introduces some redundancy in the ViewModels.
What do you think? What works for you? A clear distinction between View/ViewModel/Model or a hybrid as used by the Prism examples?
I have seen many people implementing INotifyPropertyChanged directly in their Model and similarly I have seen people doing it in ViewModel as well.
I prefer and do this(implement INotifyPropertyChanged) in ViewModel. I agree with you it sometimes create redundancy in ViewModel but I prefer a clear distinction/separatation between ViewModel and Model and what their purpose should be. To me Model is just literally a Model. It is just representation of my Business Data nothing more nothing less. To me it should not cause any change in View (through notify property changed event). View should talk to ViewModel and ViewModel should use Model. I don't like View directly affecting the Model. I don't like using Model.FirstName because to me it seems like going against MMVM by telling View what is in Model