CODEWITHSUNDEEP
wpfmvvm
matteeyah
matteeyah

Reputation: 875

Accessing ViewModel data in View

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.

Upvotes: 1

Views: 377

Answers (1)

Sergey Vyacheslavovich Brunov
Sergey Vyacheslavovich Brunov

Reputation: 18096

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.

Upvotes: 1

Related Questions