Compze.DependencyInjection 0.8.0-alpha

Compze.DependencyInjection

Pluggable dependency injection abstractions for Compze.

What is Compze?

Compze is a .NET framework for building expressive domains through Teventive programming and Typermedia APIs. Learn more

What's in this package?

A container-agnostic dependency injection abstraction with a fluent registration API, lifestyle validation, scoped service resolution, and transactional scope execution.

Registration API

// Singleton with dependency injection
Singleton.For<IUserRepository>()
    .CreatedBy<IDbConnectionFactory>(factory => new UserRepository(factory));

// Scoped with multiple dependencies
Scoped.For<IOrderService>()
    .CreatedBy<IUserRepository, IEventBus>((repo, bus) => new OrderService(repo, bus));

// Pre-created singleton instance
Singleton.For<IConfiguration>()
    .Instance(myConfig);

Every chain ends with its instantiation spec — CreatedBy(...) or Instance(...). All modifiers (AllowSingletonDependent(), WithServiceResolver(), WithAssociatedRegistrations(), ...) come before it, and the terminal call returns a finished, immutable registration.

Breaking a circular dependency

When two components need each other, neither can be constructed first. Expose one side through an IServiceResolver<TService> with .WithServiceResolver(), and have the other side depend on that resolver instead of the service — it is constructed immediately holding only the resolver, and resolves the real service later, on demand:

Singleton.For<IServiceA>()
    .CreatedBy<ServiceA, IServiceResolver<IServiceB>>(serviceB => new ServiceA(serviceB));

Singleton.For<IServiceB>()
    .WithServiceResolver()
    .CreatedBy<ServiceB, IServiceA>(serviceA => new ServiceB(serviceA));

// class ServiceA(IServiceResolver<IServiceB> serviceB) : IServiceA
// {
//    // Resolve AFTER construction, never in the constructor — that would re-form the cycle.
//    public void DoWork() => serviceB.Resolve().Handle(this);
// }

A resolver is exposed for each service type the component is registered under (so a component registered as For<IServiceB, IServiceB2>() is resolvable through both IServiceResolver<IServiceB> and IServiceResolver<IServiceB2>). Each is registered at the target's own Lifestyle and carries the target's AllowSingletonDependent()/AllowScopedDependent() opt-ins, so a dependency on IServiceResolver<TService> is subject to exactly the same lifestyle validation as a direct dependency: a Singleton still may not take an IServiceResolver<TScoped>.

WithServiceResolver() is not a core special case — it is an ordinary extension built on WithAssociatedRegistrations(), the general mechanism by which a registration spec can attach extra registrations that are added to the container alongside it. Consumers can write their own such helpers the same way.

Core abstractions

• IComponentRegistrar — Register components with lifestyle and factory methods
• IContainerBuilder — Registrar plus Build(); the configure phase
• IDependencyInjectionContainer — The built container: composes IRootResolver, IScopeFactory, and cloning
• IRootResolver — Root-level resolution (singletons, transients)
• IScopeFactory / IScope / IScopeResolver — Create scopes, own their lifetime, resolve within them
• IUnitOfWorkResolver — An IScopeResolver whose scope is paired with an ambient transaction: a unit of work. Never container-resolvable — only ExecuteUnitOfWork (or UnitOfWorkResolver.From, which asserts the transaction) grants the typing. Also the unit of work's handle: Id (a value-equal UnitOfWorkId) plus the completion hooks OnCommittedSuccessfully/OnCompleted
• IServiceResolver<TService> — Typed, deferred resolver for a single service; the supported way to break a constructor-injection cycle
• Lifestyle — Singleton, Scoped, or TrackedTransient

Safety features

• Lifestyle validation — Rejects captive dependencies at Build(): a Singleton may not depend on a Scoped component, and depending on a TrackedTransient from a Singleton or Scoped component requires the transient's explicit AllowSingletonDependent()/AllowScopedDependent() opt-in
• Duplicate detection — Catches double-registered service types
• Container cloning — Create isolated container copies for testing

Executing a unit of work

One scope and one transaction, begun and completed together — the work commits or rolls back as a whole:

container.ExecuteUnitOfWork(unitOfWork =>
{
    var repo = unitOfWork.Resolve<IUserRepository>();
    repo.Save(user);
}); // Scope disposed, transaction committed

// The deliberately-not-a-unit-of-work sibling, for work that changes nothing (a query, say):
container.ExecuteInIsolatedScope(scope => scope.Resolve<IUserReader>().Find(userId));

Installation

dotnet add package Compze.DependencyInjection

Related packages

License

Apache-2.0