Skip to content
This repository was archived by the owner on Jun 1, 2026. It is now read-only.

Proposal: Better dependency injection behavior - #310

Merged
drasticactions merged 10 commits into
drasticactions:developfrom
jasoncouture:develop
Sep 12, 2025
Merged

drasticactions merged 10 commits into
drasticactions:developfrom
jasoncouture:develop

Conversation

@jasoncouture

@jasoncouture jasoncouture commented Sep 11, 2025 •

Copy link
Copy Markdown
Contributor

The current code does a few things that aren't good practice:

  1. It creates multiple service provider instances (for the application overall)
  2. It does not use the options pattern
  3. It impedes configuration via ASP.NET configuration mechanisms.

1: This is an issue in larger apps, where creating the service collection is not the fastest process, and can cause problems when other badly behaved libraries are expecting a single instance, but there are multiple. An example would be older versions of OpenTelemetry, which was not at all a fan of being initialized more than once. Someone could have a valid reason to replace FishyFlipOptions in DI, that involved something that eventually initialized OTEL, which would result in an exception later on (the 2nd call to resolve options).

The authentication schemes are more or less static in the application, and do not need to be configurable outside of code (or when they do need to be, the caller can be responsible for doing that).

2 and 3: The options pattern makes it easier to add tests, it also allows external callers to build on top of the options. A good example here is a secrets provider that is not available during registration. By using the options pattern we allow DI based configuration, instead of manually reading IConfiguration, or requiring bad behavior to enable the secrets scenario I mentioned.

This is still compatible with the current registrations that are not using the authentication scheme properties. It just doesn't force configuration to be done via lambda/action, and allows future configuration by the caller using .AddOptions/Configure/etc.

These relatively minimal changes will make FishyFlip play much nicer with ASP.NET, and IServiceCollection/IServiceProvider

NOTE:
The obsolete properties can just be removed, they're not being used anywhere now. I left them to allow people who are upgrading to get a hint on where to go if they are customizing this (I'm sure this is actually quite rare).

The service provider should not be created until it is final, larger apps may have a lot of registrations, and it can have a major negative impact on startup performance.

Instead, allow the authentication scheme to be specified as a parameter, with a default, and remove from configuration object.

Additionally, use the options pattern for FishyFlipOptions instead of registering a singleton object. (Registered as singleton for now, will follow up with conversion to IOptions<T>)
This was done instead of removal, so that anyone using this gets a hint on where to look for the correct way to do this.
By flipping these implementations, we avoid the need to remove the registration and add a new one. Further, by not using TryAddScoped, we allow replacement using the add method since the last registration is what will be used.
Heavy handed for a single property, but allows future additions here too.
@drasticactions
drasticactions merged commit b87b200 into drasticactions:develop Sep 12, 2025
4 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants