Circular dependencies and inversion of control - how to solve those?

Question

In my application (MVVM-architecture based WPF application), I use a lot of ICommands as services. Some of those commands can be bound to menu items, toolbars, status bars etc., where they are injected into the respective container view models. Now, some of them are for instance able to manipulate data on the Shell of the application, so the Shell is a dependency of them. Since the Shell also hosts said containers (menu, statusbar...), I get a circular dependency. (Shell -> Menu -> Command -> Shell).

Currently, I use MEF to compose my application, so most of the time the problem can be solved by property or private member injection, but I have the feeling this its kind of a nasty practice (a service has no way of telling a parent that it needs this dependency, even though it does).

My question is: What is a common way to solve a problem like this:

class Shell : IShell
    .ctor(IMenu)

class Menu : IMenu
    .ctor(ICommand[])

 class ExitCommand : ICommand
    .ctor(IShell)

Answer 1

I've never used MEF, but do use a dependency injection container and have faced similar issues. The problem is, (i think) that you are throwing your Shell around as a service (providing the functionality of exiting) but it's also acting as a ViewModel (displaying menus etc). It's taking on more responsibility that it should.

Let's split your catchall "IShell" interface into separate modules to demonstrate that:

class Shell : IShell, IExitManager
    .ctor(IMenu)

class Menu : IMenu
    .ctor(ICommand[])

 class ExitCommand : ICommand
    .ctor(IExitManager)

Your shell is doing two things at once, It's ViewModel stuff (IShell) and it's managing exiting (IExitManager).

What I would do is abstract the functionality from your ViewModel. I'd create a dedicated IExitManager service. Instead of making the ShellViewModel implement this functionality, and injecting the whole thing into places that only need to trigger an exit event (dragging Menu functionality along and causing circular dependencies), instead, have that functionality in a dedicated IExitManager.

Instead of your current:

Instead bring the service out of the Shell implementation:

Your class IExitManager will need to expose the same functionality as you currently have in IShell (I presume an Exit() method) and an eventhandler ExitRequestedHandler for your Shell to listen for and perform it's action.

An EventAggregator is a basically a more generic version of this - I'd recommend you take a look at that. You could have your Shell listening for EventExit events, and your command issuing them. The only common dependency is the EventAggregator service. What this solution does is a "one off" version of this only for Exit events. If you're doing this a lot use an EventAggregator.