(Arc4u, proposal) Rethink the necessity of named service lookup

[vvdb-architecture]

Arc4u relies on "named service lookup" (as currently implemented in Arc4u.Standard.Dependency and Arc4u.Standard.Dependency.ComponentModel for 5 reasons:

• Access to token providers (i.e. ITokenProvider, ICredentialTokenProvider) by name
• Access to configuration settings (i.e. IKeyValueSettings) by name
• Access to cache methods (i.e. ICache) by name
• Access to serialization methods (i.e. IObjectSerialization) by name
• Access to a sender or received endpoint configuration for NServiceBus also uses named lookup in MessageScope, but this can be

Each of these can be reimplemented using a consumption pattern similar to what IHttpClientFactory provides for named HttpClients. That's how they avoid implementing named service lookup in their own DI library.

There is really no need to implement a "named service lookup". The current implementation is not even a "real" named service lookup, as mentioned in https://github.com/GFlisch/Arc4u.Guidance.Doc/issues/68. It would be nontrivial to correct this (and this PR doesn't even attempt to do so).

Getting rid of the current named service lookup would encourage users not to build upon it, but to work with the same "named clients" pattern. I think this is preferred over relying on an incomplete named service lookup implementation.

An illustration of what this means for IKeyValueSettings will be provided in a PR at some later date.

[GFlisch]

Ok. Do we do in this case, update the pr11?

So the dependency improvement is managed in one pr...

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: vvdb-architecture @.> Sent: Sunday, November 13, 2022 12:02:46 PM To: GFlisch/Arc4u.Guidance.Doc @.> Cc: Subscribed @.***> Subject: [GFlisch/Arc4u.Guidance.Doc] (Arc4u, proposal) Rethink the necessity of named service lookup (Issue #82)

Arc4u relies on "named service lookup" (as currently implemented in Arc4u.Standard.Dependency and Arc4u.Standard.Dependency.ComponentModel for 5 reasons:

• Access to token providers (i.e. ITokenProvider, ICredentialTokenProvider) by name
• Access to configuration settings (i.e. IKeyValueSettings) by name
• Access to cache methods (i.e. ICache) by name
• Access to serialization methods (i.e. IObjectSerialization) by name
• Access to a sender or received endpoint configuration for NServiceBus also uses named lookup in MessageScope, but this can be

Each of these can be reimplemented using a consumption pattern similar to what IHttpClientFactory provides for named HttpClients. That's how they avoid implementing named service lookup in their own DI library.

There is really no need to implement a "named service lookup". The current implementation is not even a "real" named service lookup, as mentioned in #68https://github.com/GFlisch/Arc4u.Guidance.Doc/issues/68. It would be nontrivial to correct this (and this PRhttps://github.com/GFlisch/Arc4u/pull/11 doesn't even attempt to do so).

Getting rid of the current named service lookup would encourage users not to build upon it, but to work with the same "named clients" pattern. I think this is preferred over relying on an incomplete named service lookup implementation.

An illustration of what this means for IKeyValueSettings will be provided in a PR at some later date.

— Reply to this email directly, view it on GitHubhttps://github.com/GFlisch/Arc4u.Guidance.Doc/issues/82, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABNE2KPVBKECHWIDTIJJCYDWIDDFNANCNFSM6AAAAAAR66ESDQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[GFlisch]

The fact that we are able to resolve by name is also used a lot by business applications to execute some rules based by a name stored in a DB. => For example from 1/1/2020 and 31/12/2020 for the customer x the rule to execute is named X2020.

We have to take also this in consideration.