Yep, you are absolutely right. That is one of the reasons why I started this blog… To try and make the complex simple.
IMO, for the most part, if it isn’t simple, it’s wrong.

BTW I’ll check out your course also 🙂

If the authors of the terms followed their own advice to KISS then we wouldn’t be in this mess, dont you agree? There are many developers running about (me included) thinking they are object oriented experts when in fact their knowledge is lacking or their understanding of a particular paradigm (hate that word) is plain wrong.

I agree with you. Too many definitions. But, it is a history we can’t avoid at this point.

I did a Pluralsight course on IoC that covers all of this in depth, because I wasted to make everything perfectly clear: http://psight.me/ps-ioc

A lot more than what I can type out here.

But, you bring up some great points.

From what I read IoC is also about frameworks, the “don’t call us we’ll call you” principle.

When I read that, I think of a framework like ASP.NET which allows us to plumb in our code when something happens (e.g. Control.OnPreRender(), Control.OnRender() and other overridables) – the framework calls our code when it needs to.

It’s not helpful for so many definitions to be out in the wild, in fact it’s doing my bloody head in! I despair. What should be simple things are being trumped-up to sound esoteric and advanced computing science when they do not need to be, IMHO (this applies to Liskov substitution principle as well)

I read this a few times when researching this article. As well as what Bob Martin had to say.

IMO, it comes down to this.

IoC is a concept. You can invert control in many different ways. In that same article. Martin Fowler asks the question “what control are they inverting?”

Dependency injection is one form of IoC. It just happens to be the most common.

The naming and confusion has made this really bad, and to some degree it doesn’t matter all that much.

We basically end up with 3 things.

1. Dependency Inversion Principle

2. IoC

3. Dependency Injection

Dependency inversion principle is just the idea that you can reverse dependencies.

IoC is just the idea that the actual control of the system can be inverted, through a mechanism like applying the DIP or using Dependency Injection with IoC containers.

Dependency Injection is a concrete way of applying DIP and IoC. It means to actually inject the dependencies of a class into it.

The only reason I think the difference is somewhat important is because many developers think “oh, IoC, DIP, that is all just Dependency Injection.” And, they miss out on other ways to apply the important concept of IoC and what we are really trying to do.

Sure, you can use an IoC container to do dependency injection, but why? You can’t answer why unless you understand the principles behind it.

http://martinfowler.com/articles/injection.html

“As a result I think we need a more specific name for this
pattern. Inversion of Control is too generic a term, and thus people
find it confusing. As a result with a lot of discussion with various
IoC advocates we settled on the name Dependency Injection.”

So, if he says “IoC = Dependency Injection” we should go along with Fowler, yes? My head hurts.

One way to avoid having your GUI layer depend on EF layer is to use DTO or Data Transformation Objects. Basically just classes that look like the same types in the EF layer, but you copy into a new type in the data layer. This would insulate your GUI code from depending on the EF layer code. There are some frameworks for making this easy like Automapper (https://github.com/AutoMapper/AutoMapper.)

It really depends on if you feel you need to isolate from EF. Some might argue that you shouldn’t worry about it because you are not going to change out your data persistence layer, but it really is up to you.