Question

I’m building a Visual Studio-like application in WPF and I’m having some problems identifying the best architectural design organization of my components. I plan to use Unity as my dependency-injection container and Visual Studio Unit Testing framework and probably moq for mocking library.

I’ll first describe the structure of my solution, then my questions:

I have a WPF project that contains:

• My Unity container initialization (bootstrapper) on application startup (in App.xaml.cs)
• All my application Views (XAML).

Another project called ViewModel this contains:

• All my application ViewModels. All my ViewModels inherit from a ViewModelBase which exposes a ILogger property

My initialization logic is as follows:

1. Application Startup
2. Unity container creation and registration of types: MainView and MainViewModel
3. Resolve my MainView and show it.

var window = Container.Resolve<MainView>();

window.Show();

My MainView constructor receives a MainViewModel object in its constructor:

public MainView(MainViewModel _mvm)

1. My MainViewModel has a Child ViewModel for each of its panels:

   public ToolboxViewModel ToolboxVM{get; set;}
   public SolutionExplorerViewModel SolutionExplorerVM { get; set; }
   public PropertiesViewModel PropertiesVM { get; set; }
   public MessagesViewModel MessagesVM { get; set; }
   

And I’m planning to create a InitializePanels() method that initializes each of the panels.

Now here my questions:
How can my MainViewModel.InitializePanels() initialize all those panels? given the following options:

Option 1: Initialize the ViewModels manually:

ToolboxVM = new ToolboxViewModel();
//Same for the rest of VM...

Cons:

• I’m not using the Unity container so my dependencies (e.g. ILogger) are not automatically resolved

Option 2: Use setter injection by annotating my properties:

[Dependency]
public ToolboxViewModel ToolboxVM{get; set;}
//... Same for rest of Panel VM's

Cons:

• I’ve read that Unity Setter dependencies should be avoided since they generate a dependency with Unity in this case
• I’ve also read that you should avoid using Unity for Unit Tests, so how to make this dependency clear in my Unit Tests? Having many dependent properties could be a nightmare to configure.

Option 3: Use Unity Constructor injection to pass ALL my Panel ViewModels to the MainViewModel constructor so they are automatically resolved by Unity container:

public MainViewModel(ToolboxViewModel _tbvm, SolutionExploerViewModel _sevm,....)

Pros:

• The dependency would be evident and clear at time of creation, which could help building my ViewModel UnitTests.

Cons:

• Having so many constructor parameters could get ugly pretty quickly

Option 4: Registering all my VM types at container buildup. Then passing the UnityContainer instance through constructor injection to my MainViewModel:

public MainViewModel(IUnityContainer _container)

That way I could do something like:

        Toolbox = _container.Resolve<ToolboxViewModel>();
        SolutionExplorer = _container.Resolve<SolutionExplorerViewModel>();
        Properties = _container.Resolve<PropertiesViewModel>();
        Messages = _container.Resolve<MessagesViewModel>();

Cons:

• If I decide NOT to use Unity for my UnitTests, as many people suggest,then I won’t be able to resolve and initialize my Panel ViewModels.

Given that lengthy explanation, what is the best approach so that I can take advantage of a Dependency Injection Container and end up with a Unit-Testable solution??

Thanks in advance,

Answer 1

First things first… As you noticed, your current setup might be problematic when unit testing (complex VM initialization). However, simply following DI principle, depend on abstractions, not on concretions, makes this problem go away immediately. If your view models would implement interfaces and dependencies would be realized through interfaces, any complex initialization becomes irrelevant as in test you’ll simply use mocks.

Next, problem with annotated properties is that you create high coupling between your view model and Unity (this is why it is most likely wrong). Ideally, registrations should be handled at single, top level point (which is bootstrapper in your case), so container is not bound in any ways to object it provides. Your options #3 and #4 are most common solutions for this problem, with few notes:

• to #3: too many constructor dependencies is usually mitigated by grouping common functionality in facade classes (however 4 is not that many after all). Usually, properly designed code doesn’t have this problem. Note that depending on what your MainViewModel does maybe all you need is dependency to list of child view models, not concrete ones.
• to #4: you shouldn’t use IoC container in unit tests. You simple create your MainViewModel (via ctor) manually and inject mocks by hand.

I’d like to address one more point. Consider what happens when your project grows. Packing all view models into single project might not be good idea. Each view model will have its own (often unrelated to others) dependencies, and all this stuff will have to sit together. This might quickly become difficult to maintain. Instead, think whether you can extract some common functionalities (for example messaging, tools) and have them in separate groups of projects (again, split into M-VM-V projects).

Also, it’s much easier to swap views when you have functionality related grouping. If project structure looks like this:

> MyApp.Users
> MyApp.Users.ViewModels
> MyApp.Users.Views
> ...

Trying out different view for user edit window is a matter of recompiling and swapping single assembly (User.Views). With all in one bag approach, you’ll have to rebuild much larger part of application, even tho majority of it haven’t changed at all.

Edit: keep in mind that changing existing structure of project (even tiny one), is usually a very costly process with minor/none business results. You might not be allowed or simply not be able to afford doing so. Usage-based (DAL, BLL, BO, etc) structure does work, it just gets heavier with time. You can just as well use mixed mode, with core functionalities grouped by their usage and simply adding new functionalities utilizing modular approach.