Skip to content

BaseTemplate DI Extensibility

Overview

ConnectSoft.BaseTemplate provides a default DI and middleware orchestration pipeline that can be reused and specialized by higher-layer templates (for example Identity).

The extensibility model is based on:

  • MicroserviceRegistrationExtensions as entry points
  • DefaultMicroserviceRegistration for unchanged default behavior
  • MicroserviceRegistrationBase protected virtual hooks for targeted customization

This approach reduces duplicated startup/DI orchestration code across repositories while keeping extension points explicit.

Terminology used in this guide:

  • base + add
  • replace whole step
  • default-preserving hooks
  • submodule refresh

Architecture Contract

At startup, registration calls delegate to a registration class instead of hardcoding all logic in static extension methods:

  • ConfigureMicroserviceServices(...)
  • UseMicroserviceServices(...)

Default flow remains in BaseTemplate through DefaultMicroserviceRegistration. Derived templates extend by inheriting from MicroserviceRegistrationBase.

Hook Usage Patterns

Additive (base + add)

Use this when BaseTemplate behavior should stay intact and template-specific registrations are appended.

Typical examples:

  • additional localization resources
  • named/typed HTTP clients
  • template-specific metrics

Full Step Replacement (replace whole step)

Use this when a template must alter the full registration step.

Typical examples:

  • health checks subset/scope
  • problem details strategy
  • migrations assembly selection

Common Hook Areas

MicroserviceRegistrationBase organizes hooks by stage, including:

  • domain model registration stages
  • localization, HTTP clients, and metrics
  • service discovery, redaction, rate limiting, and web security
  • API stack (problem details, REST infrastructure, Swagger, gRPC)
  • persistence and migrations (GetMigrationAssembly, migrator registration)
  • health checks and validation
  • endpoint mapping and shutdown stages

IdentityTemplate Example

Identity-style template specialization uses one derived coordinator class that overrides only template-specific stages, while reusing the default BaseTemplate pipeline for everything else.

This keeps template behavior explicit and centralized in one place.

Migration Guide (from duplicated DI code)

  1. Keep BaseTemplate defaults as the source of truth.
  2. Identify duplicated DI orchestration in derived template repos.
  3. Move template-specific behavior into MicroserviceRegistrationBase overrides.
  4. Remove mostly identical orchestration code from derived templates.
  5. Respect submodule boundaries: refresh submodule to consume BaseTemplate changes; do not edit submodule contents directly.
  6. Validate by building and running startup smoke checks (endpoints, health checks, and middleware behavior).