MVVM and avoid the monolithic God object

Question

I am at the stage of completing a large project with several major components: image collection, image processing, data storage, factory I / O (automation project) and several others.

Each of these components is quite independent, but for the implementation of the project as a whole I need at least one instance of each component. Each component also has a ViewModel and View (WPF) for status monitoring and parameter changes.

My question is the safest, most efficient and most supported way to instantiate all of these objects, subscribe one class to an Event in another and have a common ViewModel and View for all this.

Would it be better if I had a class called God that has a private instance of all these objects? I have done this in the past and regretted it.

Or it would be better if God relied on Singleton's instances of these objects to make the ball roll.

Alternatively, if Program.cs (or wherever Main (...)) is, create all these components and pass them as parameters, and then let Him (snicker) and his ViewModel deal with the peculiarities of starting this project .

Any other suggestions I would like to hear.

Thanks!

Answer 1

My preferred way to get ViewModels is to use ViewModelLocater. In principle, this is an object of God, as you mean, but the only responsibility is to create each ViewModel and save a link to it. Usually I add VML to application resources, and each view is responsible for setting the DataContext to the correct ViewModel. If you subscribe to several events, you can either connect them to VML manually, or create a virtual machine that first generates events and passes it to the dependent virtual machine in it.

Answer 2

These issues are thoroughly explored with the Microsoft "Composite Application Library" (also known as Prism) for developing WPF composite applications:

http://msdn.microsoft.com/en-us/library/ff647752.aspx

http://msdn.microsoft.com/en-us/library/ff648611.aspx

• Compiling your views . Prism has the concept of an application shell window and a region manager. A wrapper acts as a page of a blue-bone layout in which you define storage areas for a place, for example. "MainMenu" and "TabInterface". You transfer links to your views and view models in modular classes, for example. "MainMenuModule" and "TabInterfaceModule" and determine which area the module should be associated with. Prism will create your views and implement them in the shell area when the application starts. This allows you to compose your ideas independently of each other.

• The relationship between viewing modes . Prism supports an intermediary template called the Event Hub. Basically, you can publish and subscribe to messages through aggregating events from your viewing models. This allows viewmodels to communicate freely through messages, instead of knowing about each other and connecting events.

Prism protects and supports patterns for the independent development of components independently of each other, without introducing objects of God and without linking them. Most Prisms are also using IOC and dependency injection, so unit testing is much easier.

In the following article, I found a good practical introduction to using Prism and MVVM:

http://www.developmentalmadness.com/archive/2009/10/03/mvvm-with-prism-101-ndash-part-1-the-bootstrapper.aspx

Answer 3

Take a look at some dependency injection schemes, such as Unity (which uses CAL), Castle Windsor, or Spring.NET.

Answer 4

Instead of the "God" class, you can use Controllers (ApplicationController, Use-Case Controllers). Controllers are responsible for creating the ViewModel objects, and they mediate between them.

How this works is shown in the WPF Application Framework Project (WAF) .

Answer 5

I hope I understand your question well. I think using God ViewModel is not a good idea. its best to have a single view model for each of your views and create instances of all related view models in this model. then you can use an intermediary for secure messaging between the view modes of this view and other views. I also suggest using wpf commands instead of events. You can find the greate mediator article in here .