The resolved objects have the same life-time/dispose cycle as their container, that’s unless you manually dispose the transient services in code using using statement or .Dispose() method. In ASP.NET Core you get a scoped container that’s instantiated per request and gets disposed at the end of the request. At this time, scoped and transient dependencies … Read more
Decoupling is a very general principle applicable in many fields. Dependency inversion is a specific form of decoupling where you decouple the higher levels of your system from the lower levels by separating them into libraries and using interfaces. This allows you to replace lower level parts of your system without major rework. For example, … Read more
You should rarely have to call these methods at all, as you should use constructor injection where ever possible. In rare cases, such as factories or to dynamically instantiate command handlers, you can resolve it yourself. That being said, you should use GetRequiredService where you require the service. It will throw an exception, when the … Read more
If I wasn’t using a DI container, I wouldn’t have to reference EntityFramework library in my MVC3 app, only my business layer which would reference my DAL/Repo layer. Yes, that’s exactly the situation DI works so hard to avoid 🙂 With tightly coupled code, each library may only have a few references, but these again … Read more
Any place where you need a run-time value to construct a particular dependency, Abstract Factory is the solution. Having Initialize methods on the interfaces smells of a Leaky Abstraction. In your case I would say that you should model the IMyIntf interface on how you need to use it – not how you intent to … Read more
Well, it depends :-). If the class cannot do its job without the dependency, then add it to the constructor. The class needs the new dependency, so you want your change to break things. Also, creating a class that is not fully initialized (“two-step construction”) is an anti-pattern (IMHO). If the class can work without … Read more
When using a factory your code is still actually responsible for creating objects. By DI you outsource that responsibility to another class or a framework, which is separate from your code.
Wow, can’t believe that Joel would favor this: var svc = new ShippingService(new ProductLocator(), new PricingService(), new InventoryService(), new TrackingRepository(new ConfigProvider()), new Logger(new EmailLogger(new ConfigProvider()))); over this: var svc = IoC.Resolve<IShippingService>(); Many folks don’t realize that your dependencies chain can become nested, and it quickly becomes unwieldy to wire them up manually. Even with factories, … Read more
First, I want to explain an assumption that I make for this answer. It is not always true, but quite often: Interfaces are adjectives; classes are nouns. (Actually, there are interfaces that are nouns as well, but I want to generalize here.) So, e.g. an interface may be something such as IDisposable, IEnumerable or IPrintable. … Read more
The Inversion-of-Control (IoC) pattern, is about providing any kind of callback (which “implements” and/or controls reaction), instead of acting ourselves directly (in other words, inversion and/or redirecting control to the external handler/controller). For example, rather than having the application call the implementations provided by a library (also known as toolkit), a framework calls the implementations provided by the application. The Dependency-Injection (DI) pattern is a … Read more