Add Support for Keyed Registration

[dicko2]

resolves #3

[codecov-commenter]

Codecov Report

Merging #11 (54316d5) into main (9882a39) will not change coverage.
The diff coverage is 50.00%.

@@           Coverage Diff           @@
##             main      #11   +/-   ##
=======================================
  Coverage   78.89%   78.89%           
=======================================
  Files          19       19           
  Lines         706      706           
=======================================
  Hits          557      557           
  Misses        149      149           

Impacted Files	Coverage Δ
src/Agoda.IoC.Unity/UnityKeyedComponentResolver.cs	70.00% <ø> (ø)
src/Agoda.IoC.Core/KeyedComponentFactory.cs	73.33% <50.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9882a39...54316d5. Read the comment docs.

[ensecoz]

what is the decision behind using Object key and not use String key? is there any use case for non-string key? so we can avoid boxing unboxing.

[dicko2]

It's a good question, the original framework done in unit was using object as a key, so in order to make it work with the original code i needed to use object, we should probably move to string. But unsure what the impact is. I'll have a look

[dicko2]

I've updated it to string, its a breaking change to the unity implementation, but i doubt anyone is using it, the unity implementation was mainly published for historical reasons.

[joruaz]

I had my doubt about passing the dictionary while doing the autowiring and doing the registration of the key-values afterwards. Instead of just doing the key/type registration immediately. I understand we do need to check for duplicate key/type registrations so this seems to be necessary. If there is a way where we don't need the dictionary but instead use the container registration for the same checks could be more elegant

[dicko2]

@joruaz that is how it was done in the original implementation. Because Unity the container is active while you are registering.

So you can do things like this

container.RegisterSingleton<IMyObject>(myObject);
/// later on
var tmp = container.GetService<IMyObject>();
// mutate tmp
tmp.MyList.Add(stuff);
// put tmp back in the container and override the singleton
container.RegisterSingleton<IMyObject>(tmp);

With dotnet DI it has two stages

1. Register every
2. Build container

You cannot call the "GetService" until its registered and you are at stage 2, this is actually better because you can do nice validation (its almost as good as simpleinjector), but it lacks some of the flexibility.

So we need someway to maintain state. Or I think another way to implement it could be to query with linq at the end might be a bit more elegant the doing it in the foreach, but I was trying to replicate code from the old implementation which is written like this, rather than thinking through too much.. I forget to think sometimes :)

[velenom]

public bool IsRegistered(string key) => _registrations.TryGetValue(key, out var implementationType);

[velenom]

there's a ! that shouldn't be there

[dicko2]

nice catch, htf did that pass the unit test is what i need to check to