1

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.

Sergey Vyacheslavovich Brunov
  • 17,291
  • 7
  • 48
  • 81
matteeyah
  • 855
  • 11
  • 24

1 Answers1

1

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.

Community
  • 1
  • 1
Sergey Vyacheslavovich Brunov
  • 17,291
  • 7
  • 48
  • 81
  • I'm using SimpleIoC, included in Mvvm Light. It's really barebones. You can't specify behaviour other than immediate creation / on first call. It had everything I need, plus I was using Mvvm Light in the application, other dependency container libraries seemed to add unnecessary complications (in the scope of my project). [docs here!](http://www.mvvmlight.net/help/WP8/html/e2774a68-2132-6ab6-61a4-2eb3e8ae811b.htm) – matteeyah May 05 '15 at 23:29
  • @RexGrammer, could you please post the source code to demonstrate how SimpleIoC is used? – Sergey Vyacheslavovich Brunov May 05 '15 at 23:40
  • You create a static class that's the ViewModelLocator, add it to the app resources. ViewModelLocator's constructor: `ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);` `SimpleIoc.Default.Register();` Then you just expose a property `public MainViewModel Main { get { return ServiceLocator.Current.GetInstance(); } }` to which you bind a view's datacontext. – matteeyah May 06 '15 at 00:01
  • [SO Link - Info about SimpleIoC](http://stackoverflow.com/questions/13795596/how-to-use-mvvmlight-simpleioc) (incl. examples) – matteeyah May 06 '15 at 00:06
  • 1
    SimpleIoC seems to be *so simple* that it introduces complication because of "caching" (as limitation): it is required to implement registration and un-registration of the `ViewModels` to support "resolve per call behavior". I would like to recommend using another dependency injection container. Please see [the similar question](http://stackoverflow.com/questions/9342294/simpleioc-can-it-provide-new-instance-each-time-required). – Sergey Vyacheslavovich Brunov May 06 '15 at 00:14
  • So it's a the tools fault. I'll have to take all this into consideration next time I undergo a project like this. But at this point it's out of the question to switch dependency injection containers, so I guess I'll just have to stick with what I have and make due. Thanks. – matteeyah May 06 '15 at 00:26