My MVVM app has a number of views that inherit from a base user control, which exposes an "ID" property. In the XAML this is bound to an ID property on the view's underlying view model, simply:
Id="{Binding Path=Id}"
The view model implements INotifyPropertyChanged, and its ID is set in the constructor. The ID is used to uniquely identify each view/view model, and is primarily used by a "desktop manager" to manage the user controls within the main window, rather like an MDI app. When my app starts I instantiate the various view models and their views, and assign the view models to the views' DataContext. I then pass the views to the desktop manager which places them on its canvas, positions them, etc.
The problem I have is that the view's ID is still null at this point, and only seems to get bound to the data context some time later (when the UI is rendered perhaps?). I have tried forcing the binding like this, but it doesn't help:-
var bindingExpression = widget.GetBindingExpression(DesktopElement.IdProperty);
bindingExpression.UpdateTarget();
It's not the end of the world, as I can pass the desktop manager my view and the ID from the view model, but it feels a little hacky. I was curious to know at what point in the control/window lifecycle the binding occurs, and whether there was some other way to force the binding to happen?
Thanks in advance
Andy
In order to understand how bindings are transferred, you need to understand the Dispatcher. Basically, it is a priority queue. Things like layout, bindings, rendering, input, etc. are placed in the queue at different priorities.
Now, from the sound of it, you never yield execution back to the Dispatcher. This means that Binding values can't transfer (when you manually call UpdateTarget you are just scheduling this on the Dispatcher). So, in short, you need to let the Dispatcher execute the queued operations before you finish initializing.
The easiest way to do this is to call BeginInvoke at a lower DispatcherPriority on a method to finish initialization. Because of the nature of how the layout system works, it can be tricky sometimes to pick the right priority, but you'll probably be okay if you go with DispatcherPriority.Loaded.
My suggestion would be to have an interface that your View Models implement, which exposes the Id property. You can then have your Desktop Manager grab the Id from the DataContext by casting it to the appropriate interface. This is likely a cleaner separation of responsibilities, as your Desktop Manager should probably know as little about the concrete View as possible (for the sake of testability.)
Related
I just want to ask if it's OK to access the ViewModel's data in the View backend?
Basically I just need a check to see if a ViewModel's property is set (which gets set when the user selects something), and if it's not I'll just redirect the user to another View telling him he needs to select something first. Is this a poor-design practice or is it OK, just for a minor check like this? Really don't want to implement a static class and extrapolate the data to it, and check it instead.
Another question tightly related to this, is can I call a method from the View (when the View is closing), that unregisters that particular ViewModel from the IoC container (this ViewModel isn't singleton). The alternative is to send a message from the View to the ViewModel when the View is closing, and when the ViewModel gets that message it unregisters itself. The problem I'm trying to solve with this is that, every time that ViewModel is requested it has to be a new one, but my IoC container caches them, making my program a memory hog. All of the ViewModels get released on application exit, meaning x ViewModels will still exist in the cache even though they're most likely not needed.
Basically I just need a check to see if a ViewModel's property is set (which gets set when the user selects something), and if it's not I'll just redirect the user to another View telling him he needs to select something first. Is this a poor-design practice or is it OK, just for a minor check like this?
It does not seem to be wrong to check the value of some ViewModel property and reflect the changes on the View side. The View state could be "bound" to the ViewModel state by the WPF data binding mechanism: Binding, Triggers (Trigger, DataTrigger, EventTrigger), Commands (including EventToCommand), etc.
But sometimes it is useful to handle ViewModel state change by the ViewModel itself using UI Services. For example, IWindowService interface can be introduced to allow to open windows from the context of the ViewModel implementation.
Another question tightly related to this, is can I call a method from the View (when the View is closing), that unregisters that particular ViewModel from the IoC container (this ViewModel isn't singleton).
...
The problem I'm trying to solve with this is that, every time that ViewModel is requested it has to be a new one, but my IoC container caches them, making my program a memory hog. All of the ViewModels get released on application exit, meaning x ViewModels will still exist in the cache even though they're most likely not needed.
It seems to be strange that the described dependency container "cache effect" exists when the registration is specified as "resolve per call behavior" (not "singleton behavior"). Please check that the registration is specified as "resolve per call behavior" (for example, PerResolveLifetimeManager in terms of Unity Container Lifetime Managers).
Update
The ViewModel lifetime problem exists because SimpleIoC container is used.
I would like to recommend using another dependency injection container (with appropriate lifetime management) to make the implementation less complex and error-prone.
But, if there is a strong need to use SimpleIoC container, some kind of the ViewModel lifetime management can be implemented using:
SimpleIoc.Default.GetInstance<ViewModel>(key); method call to resolve an instance of ViewModel;
SimpleIoc.Default.Unregister(key); to un-register the instance when it is no longer needed (Closed event, etc).
The implementation can be found here: answer #1, answer #2.
I'm new to MVVM and WPF itself. I need to do some prototyping in WPF and reached conceptual question.
Suppose you have server which sends you data. Regardless of whether you displaying that currently or not you need to store it in cache, this is your "real data" and at some time you will need to put it on UI (when user opens particular screen), this is your viewmodel.
My question is quite obvious - should I bind UI to a real data stored in some service or should I do a viewmodel wrapper around that data and bind to it?
In the first case I receive "The calling thread cannot access this object" exceptions unless I use Dispatcher, but calling Dispatcher in model doesn't look right
In the later case I will need to:
copy 90% of the data from "real model" to wrapper
manually watch changes in underlying "real data" to update viewmodel which in case implements INotifyPropertyChanged.
What is the correct way?
The way it is most appropriate, is to have your ViewModel pretty similar to your View's needs. It means if your View has a list, then you most likely will need at lease 2 properties on your ViewModel, one for the ItemSource and the other for the selected Items.
Regarding the real data stored, I would say, put it being accessed by your service. Maybe you use the WPF or Silverlight, so you will be protecting your true physical data. And may exchange, just the proper information the view requires.
I hope it helps. If you would like to share some arquitectural aspects of your project, we might give you more advices.
I do prefer to have the Data cache in what I call the 'service layer' (the client side code that actually interacts with the server via WCF or whatever communications mechanism).
the data cache is actually several List<T> and I do not listen for change notifications in there, because that is actually not needed.
Instead, you consume these 'client side services' from your ViewModels, and retrieve the List<T> and store the items in the ViewModel in an ObservableCollection<T>. This way you can have two way binding from the View to the ViewModel, with no need for the View to interact with the 'lower level' data cache stored in the 'service layer'.
You do not need to use the Dispatcher when performing ViewModel operations, and therefore this is a better scalable approach because you can do whatever multithreading is needed to retrieve the data.
What i did
I have HomeViewModel and SellsViewModel.
In the HomeViewModel, I have property "SellID"
In the constructor of SellViewModel, i am able to Resolve reference of HomeViewModel and stored it in m_objHomeViewModel variable in SellViewModel
In the XAML of SellViewModel, i have a textbox which shows "SellID", this textbox is bound to "m_objHomeViewModel.SellID"
What i am getting doing this
Doing this, whenever user selects difference "Sell" on HomeViewModel, automatically my SellViewModel picks it up and shows changes in SellView.
Question
As XAML textbox in SellView is bound to a property in HomeViewModel, changes are getting reflected on UI immediately
But i am not able catch any event (Such as property change) in SellViewModel, catching such event i want to load other values for the selected "SellID" from database.
I am not using Event Agreegator. If used, i can easily subscribed to event in SellViewModel published by HomeViewModel
Q1: How to do it without using Event Agreegator?
Q2: If in XAML, TextBox is bound to property m_objHomeViewModel.SellID, will it create memory leakage?
Q3: If in the HomeViewModel, i get reference to SellViewModel (Using container.resolve) and call a public property or method of SellViewModel whenever "SellID" property in HomeViewModel is modified. Is it a good programming practice? Here i think it will create tight coupling between HomeViewModel and SellViewModel
Please suggest on this...
Regards
A1: If I understand your design, your SellVM will need to manually subscribe to the PropertyChanged event of your HomeVM. If the SellId property of your HomeVM raises PropertyChanged, then your SellVM will see that and respond accordingly.
A2: Without seeing the entire application, simply databinding to a property won't cause a memory leak. As long as the UI is displayed, the HomeVM will be in memory, but .NET does a pretty good job of recognizing when it is no longer needed and cleaning up the memory. The answer to this is highly dependent on your overall design, but the simple act of binding the SellID from the HomeVM through the SellVM won't, on its own, cause a memory leak.
A3: This sounds a little strange - Without understanding the full architecture, it seems that the SellID should belong to the SellVM, and when the users switches SellID, the HomeVM loads the SellVM with the appropriate SellID. This seems more OO and allows you to separate concerns. This way everything about the "Sell" (sale?) is encapsulated in the SellVM and the HomeVM is strictly responsible for coordination (loading the correct child VMs). But this is based on what little I can gather about your overall design.
I can't quite figure out how to get the view model to be notified of changes in the model without adding a bunch of UI specific stuff like INotifyProperyChanged and INotifyCollectionChanged in my model or create tons of different events and do a bunch of things that feel like they're UI specific and should stay out of the model.
Otherwise I'd just have to duplicate all the business logic in the view-model to make sure everything is up to date, and then what's the point of having the model then?
One of the tricky ones that I have in my model is a property of a "Category" class. You can think of it as a tree structure and the property is all leaf-node descendants. Well in the model that property is generated on the fly recursively through all it's children, which is all fine and good. The view-model however needs to bind to that property and needs to know when it changes. Should I just change the model to accommodate the view-model? If I do then the view-model doesn't really do anything at this point, the model raises all the necessary notifications of changes and the view can just bind straight to the model. Also if the model was something I didn't have the source to, how would I get around this?
I disagree that INotifyPropertyChanged and INotifyCollectionChanged are UI-specific. They are in namespaces and assemblies that are not tied to any particular UI stack. For that reason, I typically put that kind of behavior as low in the system as I can (usually the data layer).
If there's some reason you don't want to put it at that level, that's fine. You can put it in at a higher level such as the service or UI layer. However, you need to make sure all changes to the data structures occur through that layer also.
I'm having some fun trying to get my head around some MVP stuf, as it pertains to User Controls. I'm using .NET WinForms (or something close to it) and Supervising Controller pattern (well, I think I am :).
The User Control is itself part of an MVP application (its the View and has an associated Presenter etc). The Presenter is always started first, and it starts the Model(s) and then View(s). The View builds its UI, part of which will be to NEW the UC, which is the View.
Now the (form) Presenter needs to know about the UC Presenter, but I'm thinking that it doesn't know anything about how the View is composed. The form Presenter doesn't, for instance, know that the UC is part of the form's Controls collection, nor should it.
Furthermore, the design experience should not be changed; IOW the dev of the View (form) should just be able to select a User Control from the toolbox and drop it on a form.
So, on to my questions. Firstly, are my assumptions above correct? Somewhat misguided? Messed up? WTF are you thinking?
Secondly, is it right (enough?) to have the form View invoke the UC View, and the form Presenter invoke the UC Presenter and have some mechanism to tell the UC View what its Presenter is? This breaks my "Presenter first" rule, but I'm not sure how else to do it.
Any other thoughts, suggestions, comments gladly accepted.
-- nwahmaet
A presenter should be thought of as "autonomous state" in the presentation tier. This means that it is responsible for ensuring that the view's presentation of the model's state is in sync. The reason I bring this up is because the "pattern" of MVP often gets lost in the dogmatic view of how things should be separated. It seems that this is one reason Martin Fowler decided to try to clarify the terminology around the MVP pattern.
My favored flavor of MVP is the passive view, so my answer is based off of that.
I implement composite user controls and forms very often using the passive view pattern. There are essentially 3 different configurations:
One presenter for all user controls in the hierarchy. Flatten the view using an interface.
One presenter for each user control in the composite tree. Each parent presenter is responsible for instantiating and initializing its child presenters. The user controls are created at design time, and are able to function without a presenter (with no presentation behavior)
One presenter for each user control in the composite tree. All of the presenters are loosely coupled through a higher level controller class. The controller class is responsible for construcing the presenter, wiring them up, and coordinating their events.
Although it is a solution of last resort for me (because of its complexity), I think that the last option is the solution that you are looking for.
I've been running up against this exact problem for several months in an application I'm working on. The conclusion that I've very recently come to is that in many cases it might be impossible to apply the MVP pattern at both the window AND user control levels, without "breaking" the pattern.
My thought on it is that the user control is part of the view implementation, and the presenter should not know what is going on inside the view implementation, which means that the window-level presenter by extension should not know about the user control's presenter, and hence there should be no communication between them, including instantiation of the latter by the former. It might be argued that the user control's presenter is part of the window view implementation, and so the window view may instantiate the user control presenter. But it cannot inject the model classes that the presenter needs, because the view isn't supposed to be aware of them.
The conclusion that I think I am arriving at is that ALL user controls are view-implementation-specific, and so should be contained completely within the view silo of the larger pattern. As such, they don't get to have their own presenters... At least not bundled up with the control implementation itself. Instead they should be manipulated indirectly by the parent window's presenter, via pass-through fields exposed on the view interface. In short, the user control is exposed to the presenter not by its own interface, but rather via a common pass-through interface implemented by its parent view. Call this a "partial view interface".
Your presenter can then contain instances of a re-usable sub-presenter class which works only with this partial view interface, and the relevant pieces of the model. This will allow you to avoid re-writing the presenter code to translate from the model every time you need to use the control, AND it prevents the window view from needing to know about the model in order to pass info through to the control's presenter.
What this effectively does is it further separates the user control, as a module, from your data model. This makes sense if you think of a user control, as a whole, as an element of the view implementation. As a re-usable unit, it is a piece of view functionality, and no part of it should be tied to your data model.
Your questions is general that a variety of schemes could apply.
In this case my guess is that you should look at Observer Pattern.
You have a interface that anything that uses that view would implement. Then it would register itself when the application initializes with a collection of those interfaces. Any command that needs to update that view would traverse the collection notifying that each view should be updated.
Unlike typical examples the views would be User Controls. You have the flexibility of making any UI element implement that interface so you could use dialogs, full forms, etc in addition to your User Control.
Finally remember the User Control is NOT the view but the implementation of the View. Whatever scheme you adopt you can define what the View as deep as you want and have the User Control implement that interface.