if I remember right (it’s been 3 years), IContainer is added to the container automatically, by StructureMap.

I have gone on to build great things since then, and I have a question:

In your example, in order to allow the presenters to use the user controls created by the designer, you inject into the container the control instance in the constructor.

public MainForm(IContainer container)
{
InitializeComponent();
container.Inject(ViewEmployeeDetail);
}
My problem is, what do you do when you have a user control that contains another user control? You cannot put IContainer as a parameter, since user controls can’t handle this.

There is now a BuildUp() function in structuremap, but setter injection seems to solve a different problem …

My current work around has been to reference structure map statically like so

              public MyControl()
              {
                        InitializeComponent();
                        ObjectFactory.Inject(ChildControl);
               }

however I’d love to know if you have a way to solve this and still be able to use IContainer rather than the static instance.

thanks again
Dave

I’ve basically completed the “real world” example application for my upcoming presentation. I decided to use a very simple Org Chart as the sample app. There are a few key pieces of the sample app that I’ll try to outline further, in another blog post: on the main form, I’m using the EventAggregator to get notification of employees being added, and employees being selected from the org chart to display their info. I’m also using an ICommand to kick off the add new employee wizard, and using a workflow service object to run the add new employee wizard.

I hope that this app, being a little more “real world”, will help to shed some more light on the AppController and the other patterns that are in play, for you.

You can get a copy of this app from my Github repository, at:

http://github.com/derickbailey/presentations-and-training/tree/

under the “Decoupling Workflow With App Controller” folder.

In any case, I really hope to get an “Ah-ha!” moment out of your presentation. Right now I’m using the MVP pattern as described by Craig Shoemaker in his site. The separation of logic is nice, but I still run into a lot of coupling problems when one form has to instantiate and call another and depends on what the user did or entered in that other form.

Something that I missed the first time around (I think I was speedreading through it just before leaving work), was the idea of using an IoC container to achieve this level of decoupling. I’m yet to use an IoC container, but putting it in context, your code makes a bit more sense now. Time to go read up on IoC containers…

Glad the post helped at least a little! I’m currently writing a much more elaborate, closer-to-real-world example app and presentation based on this blog post, and am hopefully going to be giving a presentation on it at the upcoming Austin Code Camp, on May 30th.

I know you’re not in the Austin area (saw your Twitter location), but I’ll be posting the complete presentation and solution on my blog some time soon after the code camp. Hopefully it will be a little more enlightening. :)

Again, (like Jeremy said) thanks for writing about Winforms in this age of Web/Silverlight/WPF.

@Derick: fantastic post! Really enjoying your blog since I’ve found it. Since we’re doing WinForms development it’s nice to see some great blog posts about WinForms in the age of WPF and Silverlight. :-)