Posted by: jsonmez | August 15, 2011

Inversion of Control Course Published on Pluralsight

Just published my 4th course for Pluralsight, Inversion of Control.


I was pretty excited to get the opportunity to do this course, because there is a large amount of misunderstanding out there about:

  • Inversion of Control
  • Dependency Injection
  • Dependency Inversion Principle
  • Inversion of Control Containers

I cover each of these topics in this course and then we even build our own IoC container.

If you liked the Back to Basics series, you’ll like this course.  I go and dive a pretty deep into the real meat of the patterns and principles behind IoC containers.  Then I cover using Unity and Castle Windsor.

I think it is pretty important that we understand clearly why we are using a particular technology or pattern and what problem it is trying to solve.

I see too many people jumping on the bandwagon of so many popular technologies without really taking the time to learn the background about the technology to understand why it is an effective solution to a problem and what problems it attempts to address.

As always I welcome any feedback or suggestions for future courses.



  1. […] Inversion of Control Course Published on Pluralsight (John Sonmez) […]

  2. John,

    Great job on the Pluralsight IoC course… It brought a lot of the concept together for me in a short time.

    One question though. In your “Using Unity” module, you’re lesson on “Controlling LifeCycle” showed how you could create a second shopper which you named shopper2, but then in the Console.Writeline just below it, you were outputting the first shopper… but you didn’t seem surprised with the results you were getting. I was expecting something else to come from the output since you were outputting shopper and not shopper2. Can you explain?


    • Thanks Scott,

      I think I understand what you are asking, let me know if this clears things up.

      So in that case, I could have used shopper or shopper2, because I was demonstrating the lifecycle of the MasterCard object that was being injected.

      So in the case where MasterCard is a singleton, shopper and shopper2 both have an instance to the same card. So when one charges the card, it increases the charge count for either shopper. I could write out from either shopper and the charge total should be the same.

      When it isn’t a singleton, then each shopper has it’s own card. So when I did the writeline there for shopper, I was showing that it wasn’t incremented by what shopper2 had done.

      Really I could have done a writeline of either and could have demonstrated the same concept. I do see how it is somewhat confusing though.

      Basic idea is, singleton = shared instance of MasterCard, non-singleton each has their own instance.

  3. John,

    Thanks for the explanation. I guess it was getting a little late last night and I should have thought about it more the next day. I got it now.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: