0

Suppose I have a Windows WPF application (SampleApp) that is using IoC (Ninject). I have wired up everything in my composition root as follows.

[STAThread]
static void Main()
{
   IKernel kernel = new StandardKernel();
   var modules = new List<NinjectModule>
   {
      new ExternalDependencies(),
      new DependencyResolver()
   };
   kernel.Load(modules);
   var mainWindow = kernel.Get<IMainWindow>();

   mainWindow.ShowDialog();

   kernel.Release(mainWindow);
   kernel.Dispose();
}

The Conents of ExternalDependencies can be ignored for this example, but here are the contents of DependencyResolver which is for internal dependencies.

class DependencyResolver : NinjectModule
{
  public override void Load()
  {
     Bind<IMainWindow>().To<MainWindow>().InSingletonScope();
     Bind<IProductWindow>().To<Product>().InSingletonScope();
  }
}

As you can see, I have MainWindow and Product wired up. The ctor on MainWindow looks as follows.

public MainWindow(IDomain<TaskFields, TaskExtFields, TaskEmbeds> task)
{
   _task = task;
   InitializeComponent();
}

We're all good to this point. However, now I am at the point where I would like to have actions in the main window (button clicks, menu selections, etc) open various other forms. For example I have a Product window as follows and I want a button click to open the window and wire everything up appropriately.

public Product(IDomain<ProductFields, ProductExtFields, ProductEmbeds> productDomain)
{
   _productDomain = productDomain;
   InitializeComponent();
}

Looking to keep my IoC from leaking out of the Main method. In other words I don't want the code to look like...

var productWindow = GlobalIoC.Get<IProductWindow>();

which would violate the three R's principle, require me to make the IoC global and leak information that I hope is not needed out into the rest of the code.

Right now I am dealing with 2 or 3 windows for testing - however in a final application I can see this growing to a larger number, say perhaps hundreds of windows each with their own backing viewmodels (when I get through this I will be implementing viewmodels), domain, data models, repositories, etc.

I have all of this working for the main form but I cannot wrap my head around how to properly wire everything up so that it's available, and stays in the composition root.

To be clear, this is currently a learning project (IoC, MVVM, DI)

Suggestions?

Brian Mueller
  • 171
  • 1
  • 8
  • After more searching I am currently reviewing the answer at http://stackoverflow.com/questions/20242817/resolving-windows-in-structure-map-or-how-to-manage-multiple-windows-in-wpf-mvvm?rq=1 to see if it is relevant and is a direction for my problem. If I determine that it's good and relevant I will make that the answer. – Brian Mueller Mar 24 '15 at 20:37
  • FYI, I haven't used WPF or Ninject but have worked with similar frameworks and libraries and since I don't see any answer to this question, am just writing my perspective of how I solve such things. Maybe that would help. – Aman Agnihotri Apr 02 '15 at 17:29
  • So here's how I do it: My views know about the buttons that can be clicked or labels on the screen that can change their text. When a button is clicked, the view informs its mediator via a local custom signal/event, and the mediator then dispatches a signal globally that then triggers a command which uses the models and services in my program and processes the logic part. The command after having done its work dispatches a signal which mediators of various views might be listening to. These signals can carry information with them. The mediators then make appropriate changes to their views. – Aman Agnihotri Apr 02 '15 at 17:30

0 Answers0