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..

@@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.

You are welcome.

Thank you!

You are welcome.

I am glad it was helpful.

You are welcome.

You are welcome.

You are welcome.

Thanks!

You are welcome.

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.

@@IAmTimCorey Makes sense! Good advice! Thank you

Nick Chapsas has a video on that

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.

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

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.

@@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!

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

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.

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

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.

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.

😉

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

Thanks.

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.

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

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

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

Why

Where is "Messages" displayed?

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.

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