CODEWITHSUNDEEP
.netwpfmvvm
Eric Anastas
Eric Anastas

Reputation: 22213

Where should startup logic go in MVVM?

I'm writing my first WPF application using MVVM, and I'm a confused about the role of the View Model and where I should put code that should run when the application is started.

My application is very simple. It lists files from a remote location which the user can then select from to be copied to their own computer. When the application first starts it must determine the current source of files from a configuration file, read the current files at the source, and lists them to the user in the main window. If the configured file source can not be found then the user will be prompted to select a source.

Should this logic go in the ViewModel? If so should it go in the constructor of the view model? This doesn't seem right because I don't want the ViewModel reading configuration files, and prompting the user anytime it is instantiated.

If this were a WinForms application I would do this in the Form.Load or Form.Shown event.

Upvotes: 3

Views: 3368

Answers (3)

Andrey Alonzov
Andrey Alonzov

Reputation: 357

It's a good practice not to do complex logic in the ctor. As already said, it is better to define Initialize() method (even better if it will be a member of IInitializable interface).

If your app is really simple and there are no plans to extend it much, you can combine Model and ViewModel layers and do all the job right in ViewModel. But if your app is complex enough, Model classes should be injected through the constructor to a ViewModel. Model classes contain all the logic and ViewModel uses them to perform action and display data.

Upvotes: 1

Mare Infinitus
Mare Infinitus

Reputation: 8162

If you have a simple application and startup is known to be not lengthy, you could bootstrap your application utilizing unity.

Everything on doing that is shown in a really good video introduction to MVVM available here: Jason Dollinger on MVVM

The sourcecode he developes in this video is also available: Source code of the model-view-viewmodel video

Besides that, your bootstraping logic (reading config, ...) should clearly be controlled by the viewmodel. You can still have a ConfigSource, which does the reading and that can be run in a background thread.

Implementing that Source, you can have an interface, which makes it easy to exchange your ConfigSource against one that reads the data from a database or elsewhere. AND: you can get such an instance from unity, decoupling more from a concrete implementation. You could use constructor injection with such:

i.e. viewmodel is bootstrapped => gets a ConfigReader injected => call to ConfigReader (on BackgroundThread) => View get filled

Upvotes: 3

Vinit Sankhe
Vinit Sankhe

Reputation: 19885

Usually the main data loading code can be kept in a separate viewmodel function such as ViewModel.Initialize()... more importantly on a background thread coz that will not hang the GUI while its executing and till that moment you can show a busy waiter aimation on the GUI.

You can make it Command driven for your ease (e.g. Relay/DelegateCommand such as InitilizeCommand) and Initialize() method can be the command's Execute delegate.

Initialize() can be called based on your convenience... start in in the ViewModel's constructor, or handle the Window/UserControl.Load event using attached behavior and schedule the "ViewModel.Initialize()' function, as long as the function is on a different background thread, we are good.

If you use patterns and practises of PRISM, the data loading like this, can be fitted automatically into specific modules as part of that whole design of composite GUI that Prism represents.

A Good MVVM tutorial is here ... http://msdn.microsoft.com/en-us/library/gg405484%28v=pandp.40%29.aspx

Upvotes: 4

Related Questions