Dependency Injection Updates in .NET - Keyed Implementations

[@Sander-Brilman]

Nice video. great you not only showed how the feature works but also the edge cases (such as blazor components) and how to do it propperly by not using magic strings but rather enums. quality content.

[@IAmTimCorey]

Thank you!

[@TichShowers]

I think a good use case is removing factory classes to essentially do the same. Instead of injecting the factory and calling a method that performs the switch case, you can just call for the correct injection.

[@aimene_.]

How could you call a specific class if the keyword is specified in the constructor parameters? I don't think this will replace the factory pattern..

[@TichShowers]

@@aimene_. Only factory classes which do service determination based on a single static key are going to be replaced. Like getting a filestreamvalidator based on file type. the interface can be the same, but the implementation really depends on the file type being validated. The use case isn't extremely common, but can be useful nonetheless.

[@mrsajjad30]

Thank you Mr. Tim Corey for taking your time and making it easier for us.

[@IAmTimCorey]

You are welcome.

[@TuanAnh-hc1nm]

This is a really useful feature, especially for testing. I used to spend hours with headaches on this

[@IAmTimCorey]

I am glad it was helpful.

[@manuelgamezz]

Thanks Tim, It's an easy example to understand the new feature.

[@IAmTimCorey]

You are welcome.

[@talkathiriify]

Mr.. Cory Your solutions always greate and excellent. Thank you so much for your time and efforts.

[@IAmTimCorey]

You are welcome.

In 3:18 what is the shortcut for removing the curly braces from namespace?

[@IAmTimCorey]

Just put a semicolon at the end of the namespace declaration.

[@ludovicwagner2656]

Is it possible to dynamically select which implementation to use inside the constructor based on a value obtained from appsettings.json via IConfiguration?

[@BrentHollett]

Can the selection be specified at Runtime? We have similar services on the same interface for different versions of a platform that we're interfacing with, and we dont know which one we need until runtime.

[@codeme8016]

Wonderful contents. Thanks for the update!

[@IAmTimCorey]

You are welcome.

[@aimene_.]

If i understand, it will not replace the factory pattern. For example if we want to implement a specific class depending on the configuration in appsettings.json ?

[@IAmTimCorey]

You could do that now with dependency injection (no need for an additional factory pattern). Just have a method that checks the settings file and then adds the appropriate dependency to DI at startup.

[@peng943]

Could you please help answer what is the benefit of this comparing to inject multiple interface implementations? Even the key is a Enum, it still looks like magic string smell in a certain way.

[@IAmTimCorey]

It reduces the need for unnecessary interfaces. Imagine you have an IDatabase interface. Then imagine you have implementations for SQL and SQLite. Now imagine your application actually uses both, not just one. You use SQLite for client-side storage in your WPF app and your SQL for server-side storage when your system is online. You could create ISql and an ISqlite interfaces that inherits from IDatabase so that you could add both to dependency injection. Or you could make them keyed services.

[@404-UsernameNotFound]

3:19 Is there an advantage to using the traditional constructor like you did vs the new primary constructor in .net8?

[@seesharp81321]

Nick Chapsas has a video on that

[@grantpeterson2524]

Thanks so much for this video! Very helpful. One thing I'm wondering is what is your recommended pattern for utilizing keyed "Options" would be? Maybe I'm just completely misusing `IOptions`, but when I try and add a keyed option using `IServiceCollection.Configure`, the `name` argument only allows a string, not an enum like I was hoping. What would your approach be? And are there any attributes I can utilize like with keyed service to ensure I'm injecting the correct `IOptions` directly? Thank you!

[@clebersondot-net]

I liked this way to injected with Blazor. But and the other way using "normal" singleton without keyed? We doens't need using anymore?

[@jirinovotny9704]

You still can use "unkeyed" registrations unless you have more implementations for an interface that you want to switch between. Having a keyed registration in the DI container when there is just one implementation doesn't make much sense.

[@waynehawkins654]

Nice - thanks Tim.

[@IAmTimCorey]

You are welcome.

[@alessandrocaliaro9808]

Hi. Does this work also for MAUI?

[@IAmTimCorey]

Yes. MAUI now uses the same .NET so the features all work.

[@johnytodorov3129]

Hello Tim, I want to ask do you know how this keyed implementations, will work with Unit Tests, I mean how you can mock object of Interface but with specific "Key" ?

[@IAmTimCorey]

Create a keyed mock that you pass into your DI container.

[@catalinmarianmursa7892]

Great video!

[@IAmTimCorey]

Thanks!

[@paulegan3783]

Thanks Tim. What's the benefit of this over just asking for an instance instead of the interface in the Demo class? For example for the constructor: public Demo(InformalMessages messages){} Isn't the whole idea of injecting interfaces to give the user of the class a choice of which instance to inject? (Sorry if that's a newbie question or I'm missing something obvious).

[@jirinovotny9704]

The DI container in Tim's demo actually has two registered implementations for IInteractionMessages interface. The default behavior of the built-in DI container from Microsoft if you wrote your constructor like public Demo(IInteractionMessages messages){} is that it provides the last registered implementation which in this case was the "relaxed" implementation. You would always get the last one, in no way you could get the formal one unless you asked for IEnumerable in the constructor or wrote a factory class. The new feature of the DI container in .NET 8 is that you may pick a specific implementation in the constructor itself by using the key you used for registration. So you do not need a factory class or factory method which you needed in previous versions to achieve the same behavior.

[@paulegan3783]

@@jirinovotny9704 Ah ok, that's helpful thanks 👍

[@jirinovotny9704]

I've just noticed you were asking for the specific implementation class in your constructor. It is possible to ask for specific implementation but you would have to have it registered in the first place (which Tim didn't do), otherwise you would get a runtime exception. Asking for an implementation class also defeats the purpose of IoC and the decoupling of abstraction and implementation. You would end up in having tight coupling between your Demo class and InformalMessages class which is not the best practice.

[@paulegan3783]

@@jirinovotny9704 Yeah I initially interpreted the key as creating tight coupling just like asking for an implementation class. I'm gathering this is not the case although it's not clicked why yet for me. I think I need to learn a bit more about the Microsoft DI container and how it works. Thanks for your responses, much appreciated!

[@MiningForPies]

@@paulegan3783you can of course ignore the attribute when manually constructing objects, say when setting up unit tests.

[@FireIn8]

Thanks!

[@IAmTimCorey]

You are welcome.

[@darylbeaumont8855]

Great video, Tim! A more specific question on Blazor: is extracting the code into its own code-behind generally recommended most of the time? It feels as though you have more control in code-behind. I’ve not really used Blazor up until now, so I’m curious!

[@IAmTimCorey]

It really depends on the amount of code you have in the code behind. I personally leave it on the page unless it gets larger. And then I evaluate if I'm doing too much on the page.

[@darylbeaumont8855]

@@IAmTimCorey Makes sense! Good advice! Thank you

[@olegsuprun7590]

I don't see a big use case for this. First of all we already have a way to do it via registering a delegate in the IOC that constructed a correct service based on some parameter. Second issue: the only time we need to have multiple implementations registered is when we need to decide at RUNTIME what implementation we need to use. By injecting the concrete service with an attribute we are neglecting all the benefits of flexible runtime behavior.

[@IAmTimCorey]

The statement "the only time...(is) at runtime" makes me twitch. Whenever you catch yourself saying "always" or "never" or their equivalents, you are almost certainly wrong (even in that I didn't make it absolute because there are probably edge cases). For example, you may have two services that do something similar like texting a confirmation vs emailing. In certain circumstances, you might want to do both (and the interface would be the same so you could). In other cases, you might want to only do one or the other. You might want to email a receipt (but not text the whole receipt), you might want to text a confirmation code, and you might want to both email and text delivery information. That would be a design-time decision, not necessarily a runtime decision. There are lots of people that were using the existing functionality of multiple implementations for one interface and then choosing the one specific one they wanted after getting the list (but still at design time). This change just makes it easier for them. No, it isn't going to be an everyday solution, but it is a solution that will make some code much cleaner.

[@sakenda]

You could have done the same in the code section with the inject attribute

[@IAmTimCorey]

Keyed implementations aren't supported as injected values in Blazor yet. Not unless you use the code behind in a separate file.

[@DagothThorus]

Behind the counter... I see what you did there :)

[@IAmTimCorey]

😉

[@ashpro5339]

I think the tutorial is not completed...

[@allthecommonsense]

Why

[@DaveYadaraf]

Where is "Messages" displayed?

[@IAmTimCorey]

The point of the tutorial wasn't to create a working application. The point was to show how to get keyed dependencies out of dependency injection. I did that. I just didn't show how to then use those dependencies. That was outside the scope of the tutorial.

[@jeffreystines7833]

Instead of using an enums for the key could you use nameof()?

[@saulasheriffdeenolamilekan4540]

nice...

[@IAmTimCorey]

Thanks.

[@chrisl8292]

4:10 - it's pronounced E - NUM. Num as in number. In 25 yrs of being a dev, first time I've EVER heard someone call it a e noom. 😮

[@IAmTimCorey]

Don't start trying to gatekeep pronunciations. Those vary per region. There are a lot more important things to worry about.