In places around your code base, you'll end up with code like this:
var serviceA = namedServices("A");
This works, but later you want to change the name the service is registered with on startup:
namedServices.AddSingleton("AwesomePaymentService", new PaymentService());
Suddenly code in libraries may break as they fail to resolve the service using the old name. You may have been through the code base and renamed all the names but perhaps the code in question is in a library? Or perhaps your solution is huge and you don't want to change this.
You can now workaround this by using the ForwardName API to forward a name to another name:
namedServices.AddSingleton("AwesomePaymentService", new PaymentService());
namedServices.AddSingleton("OldPaymentService", new OldService());
namedServices.ForwardName("OldName", "AwesomePaymentService");
Now all your consumer code can continue to request the service with "OldName" but the resolution will be forwarded to the service you've named "AwesomePaymentService". New code can just use "AwesomePaymentService" when requesting the service if you think thats helpful.
This is a feature idea for
NamedServicespackage.Suppose you register a service named "A".
In places around your code base, you'll end up with code like this:
This works, but later you want to change the name the service is registered with on startup:
Suddenly code in libraries may break as they fail to resolve the service using the old name. You may have been through the code base and renamed all the names but perhaps the code in question is in a library? Or perhaps your solution is huge and you don't want to change this.
You can now workaround this by using the
ForwardNameAPI to forward a name to another name:Now all your consumer code can continue to request the service with "OldName" but the resolution will be forwarded to the service you've named "AwesomePaymentService". New code can just use "AwesomePaymentService" when requesting the service if you think thats helpful.