Monday, October 21, 2013

New Pluralsight Course: Dependency Injection On-Ramp

My latest course is now available on Pluralsight: Dependency Injection On-Ramp.

Dependency Injection On-Ramp
What is Dependency Injection? The answers to the question seem to cause more confusion than help. This course will get us started on the road to understanding. We'll take an example-based approach to see the problems caused by tightly-coupled code. We'll add Dependency Injection to trade that tight-coupling for loose-coupling. And that loose-coupling makes our applications much easier to extend, maintain, and test. Finally, we'll see how Dependency Injection Containers can provide benefits that would be difficult to implement ourselves. This just scratches the surface. Once we're done, we'll be ready to start our journey on the Dependency Injection superhighway.
I've really enjoyed presenting on Dependency Injection over the last year -- I've given my live presentation 12 times since October 2012.

One of the reasons I really like this topic is because I've found it extremely useful in my own development. It took me a while to get the hang of it and to see the usefulness. But once it clicked (the "a-ha" moment (no, not that "a-ha" moment (but that's a good one, too (I miss the '80s)))), it's hard to imagine building complex applications any other way.

My goal is to give a short-cut to that "a-ha" moment. We can't cover everything we need to know about Dependency Injection in such a short time, but we can get a good understanding of the basic concepts and, more importantly, see real code that shows why we may want to use it in our own applications.

This may be my best course yet. Check it out and let me know what you think.

Happy Coding!


  1. about 2/3s through it - and it's AWESOME.

  2. Excellent. Jeremy. I like the "on-ramp" theme you have going. I like your clarity and brevity. I anticipate the courses that follow.

  3. Great course...completed it once..I will see the session once again...Currently watching the other course on Design Pattern...

  4. I am just over halfway through the course and I am really learning a lot from it. Do you have another course or post on how to implement this if you already created your EDMX? I am starting a new project and hope to do some of the things I've been reading and doing small tutorials about (MVC, EF, DI, TDD) but I think I already messed up when I created my EDMX from the database.

    1. Having already created an EDMX doesn't affect how you implement the rest of the application (layering, MVC, DI, etc.). What's more important is how you use the entities. If you are making EF calls in the code-behind of a form/window, then you (probably) need an additional layer, such as a View Model or a Controller.

      I'm not an expert in EF; I generally end up fighting with it whenever I use it. But it is simply the Data Access part of the application. You can still build Models on top of EF (if you need them). And there is nothing to stop you from using TDD to build the application -- although you will probably need to create some fakes or mocks for the data in the tests (which is normal).

      If you are worried that you don't have a Repository (as is shown in the DI samples), then you might want to check out this article: Do I Really Need a Repository? ( You might not need one for your particular application.

    2. Thank you for the link and advice. Based on your linked article it does seem like this project would benefit from using a repository (unit testing and the possibility of swapping out data stores). I guess my confusion is how to do this with EF, it feels like I would be replicating a lot of code; the entities in my model into normal getter/setters. Of course this could just be due to me being new to using this kind of architecture, like in your article I work in a corporate environment which is pretty static. Normally my layers are Data Access (EF), a business logic layer that uses the EF, and a view layer that uses the business logic.

  5. Great course. Dependency injection containers were awesome.