1

I'm writing an application in WinForms and wondered whether to use an IoC or a Container.

What we're writing is a text-editor for our home grown BASIC style language for calculating fees etc. Its something like Notepad++ but not as much functionality and a debugger.

I'm wondering whether I should be using a Container or an IoC and which I should opt for. Being a WinForms application and having to do quite a few things at startup (Loading syntax engine, UI configuration etc) do you think I can even use an IoC?

With a container, I can make it a static class and just do Container.GetInstance() but I can't see how one could wire up an IoC when some classes will depend on others etc.

I also have quite a number of commands that I want to use the COmmand Pattern for, so define an ICommand and extend with ITextCommand, IFormulaCalculationCommand, IDebugCommand for specific areas. How would I even use IoC to say get the active document within a Tab from one of those commands?

Its all very confusing to me right now and I apologise.

Here's a few short questions if you can't answer the above cleanly :)

  • What's the fastest and simplest Container (ServiceContainer?)
  • Would you recommend an IoC like Autofac for this Windows Forms project?
  • Can you implement IoC and still use the command pattern to invoke commands and get teh active document being edited etc?

1 Answers1

2

First of all, "IoC" means "inversion of control" and it is a concept (not a concrete software component) that is highly related to dependency injection. The container (which is a software component) is a dependency injection container. So not only are "IoC" and "container" two entities that cannot be compared, they are also inside the same "camp" so to speak.

Therefore the question could better be phrased as "should I use a DI container for my application?".

There are several DI containers you can choose from: Microsoft Unity, Castle Windsor and NInject are a few of the more well-known ones (I was unaware of Autofac until now). Pick one and go ahead with it; there will be no practical difference in your case and you can always switch relatively easily to another one if the need arises.

Further, a major selling point of containers is that you do not need to wire them up to construct classes with deep dependency trees. The container resolves and injects the dependencies automatically; you only need to help if you need object construction to happen with specific values passed to a constructor.

Finally, there is no relation between a DI container and the command pattern or anything like that. If you want to get the active document, then simply store what the active document is in a variable whenever it changes and read that variable when you need. The container does not come into it at all.

Update: Adding a link to the highly relevant question Which .NET Dependency Injection frameworks are worth looking into?

Community
  • 1
  • 1
Jon
  • 428,835
  • 81
  • 738
  • 806
  • Thanks for the answer, is there a good example of a text editor written using DI techniques thats simple? I looked at SharpDevelop but its too complex to pull apart. – Sophie Crystal Taylor Apr 06 '11 at 12:57
  • @SophieCrystalTaylor: I don't think there's a good example of a *text editor* using DI anywhere. The people who understand DI do not need such an example, and the people who do not are better served by more introductory examples; there is no need to bring text editing into it. Decide on a container and read the tutorials for it. – Jon Apr 06 '11 at 13:00