Abblix.DependencyInjection 2.4.0

Abblix.DependencyInjection

Extensions over Microsoft.Extensions.DependencyInjection for the patterns a modular library actually needs: aliasing one registration under several contracts, composing many implementations into one pipeline and editing that pipeline afterwards, decorating registered services, and constructing services with per-call overrides. This is the DI layer behind Abblix OIDC Server, usable on its own in any .NET application.

Advanced DI in .NET is the long form: the same ladder from aliases to an editable pipeline, with the reasoning behind each rung and what it costs.

Install

dotnet add package Abblix.DependencyInjection

Aliasing

One implementation, several contracts, one instance:

services.AddSingleton<TokenService>();
services.AddAlias<ITokenIssuer, TokenService>();
services.AddAlias<ITokenRevoker, TokenService>();

TryAddAlias and TryAddEnumerableAlias follow the framework's TryAdd semantics, so a host's own registration wins over a library default.

AddKeyedAlias<TService, TSource>(serviceKey, sourceKey) is the same idea for keyed registrations: the alias resolves to the instance already registered under the source key, so a type dispatched by a wire value - an alg, an event type - answers a second contract without a second instance.

Composition: many implementations behind one contract

Compose collapses a family of registrations into a single composite behind the singular contract - the shape of a validation pipeline, a chain of handlers, a set of strategies consulted in order:

services.AddTransient<IValidator, SyntaxValidator>();
services.AddTransient<IValidator, BusinessRuleValidator>();
services.Compose<IValidator, CompositeValidator>();

What makes this composition editable is Decompose: a live cursor over the composed members that a host uses to adjust a pipeline a library assembled, without rebuilding it:

services.Decompose<IValidator>()
    .AddBefore<BusinessRuleValidator>(ServiceDescriptor.Transient<IValidator, TenantPolicyValidator>())
    .Remove<SyntaxValidator>();

Members keep their own lifetimes, the composite adopts the shortest among them, and edits act on the registrations themselves - there is no hidden side registry to drift out of sync.

Decoration

Decorate wraps whatever is currently registered, preserving its lifetime - the standard way to add a cross-cutting concern without touching the original registration:

services.Decorate<ITokenValidator, LoggingTokenValidator>();

Both operations have keyed counterparts: ComposeKeyed and DecorateKeyed.

Per-call overrides

Dependency.Override constructs a service from the container while substituting only the named dependencies - the clean alternative to hand-built factories that freeze a constructor's shape into calling code:

services.AddSingleton<IReplayCache>(provider =>
    provider.CreateService<DistributedReplayCache>(
        Dependency.Override("Abblix.SecurityEvents:ReplayPrevention:")));

Overloads accept a type mapping, an instance, or a factory, and the same overrides ride the AddSingleton / AddScoped / AddTransient overloads this package adds. Every dependency not overridden resolves from the container as usual, so a new constructor parameter on the service does not break the factory.

Registration inspection

Find, FindRequired, FindAll, RemoveAll and ChangeLifetime operate on the registration list itself - the tools for the rare but real cases where a host must inspect or reshape what a library registered.

Part of the Abblix product family

The composition and decoration machinery here is what lets Abblix.OIDC.Server ship assembled pipelines a host can still edit; the full family lives in the repository.

License

Abblix.DependencyInjection is licensed under the Apache License 2.0.

Contacts

• General inquiries: info@abblix.com
• Support and security reports: support@abblix.com
• Website: Abblix OIDC Server