News

Dependency injection across Angular and .NET

Dependency injection is often described as passing the things a class needs into its constructor. That definition is accurate, but it misses the architectural purpose: the code using a service should not also decide how that service is created. A component asks for an invoice repository; the application supplies a concrete implementation at startup. This separation keeps business rules away from object construction and gives each dependency a deliberate lifetime.

The same idea spans Angular and .NET, where a dependency might be an HTTP client, a database repository, a clock, or a feature flag. In Angular, providers form an injector hierarchy. In .NET, IServiceCollection forms a composition root from which the host builds its service provider. The APIs differ, but the design question is identical: where should creation happen, and who is allowed to choose the implementation?

Why injection changes application design

The payoff is not fewer constructor parameters; it is control over boundaries. A pricing rule can be tested with a fixed calculator, a payment workflow can switch from a sandbox gateway to a live one, and an HTTP call can be replaced with a recorded response. These changes let infrastructure evolve without rewriting the code that consumes it.

Think of the familiar Australian flat-white ritual. The drink is ordered as one outcome, while the café controls the grinder, beans, milk, and machine. The customer does not need to assemble those ingredients, nor should the order taker become responsible for repairing the espresso machine. Constructor injection follows that separation: the consumer states what capability it needs, while the application wiring selects the implementation.

Bad wiring often appears as a general ServiceLocator that hides constructor dependencies, or as a giant ApplicationContext that constructs unrelated features. Those patterns create hidden costs and unclear ownership. Good injection keeps dependencies visible, limits each object’s responsibilities, and leaves a composition root where concrete choices can be reviewed.

Angular’s injector hierarchy in practice

Angular’s injector hierarchy is more than a convenience for framework registration. A component can resolve a provider from its own element injector, then from an environment injector, and finally from the root injector. providedIn: 'root' creates a root-level default; a provider listed on a component creates a child instance tied to that component; route or application providers can supply environment-specific values. The nearest matching provider wins, so scope should follow the lifetime of the state being shared.

Registration style determines how much of the graph you must maintain. Prefer providedIn: 'root' for stateless application services unless another lifetime has a clear reason. Use InjectionToken for contracts that do not correspond neatly to a class, especially configuration objects and feature gates. A token can be backed by useValue, useClass, useFactory, or useExisting, allowing the same consumer contract to move from a mock to a real implementation without changing its constructor.

Modern Angular also supports inject() inside an injection context, which is convenient for functional providers and field initialisation. Keep it away from arbitrary methods where the dependency would become invisible. If a value differs between local development, CI, and an Australian deployment, put the difference in environment providers rather than branching throughout components. Those choices prevent a Sydney production build from accidentally retaining a Melbourne development endpoint.

.NET lifetimes and service registration

IServiceCollection is .NET’s composition root. Extensions such as AddSingleton, AddScoped, and AddTransient register services by contract and implementation, while TryAdd variants preserve an existing registration when configuration is composed from several libraries. A singleton suits a process-wide cache, a scoped service suits work belonging to one request, and a transient service receives a new instance for each resolution. Naming a lifetime accurately is part of defining the dependency’s contract.

The classic mistake is a captive dependency: injecting a scoped repository into a singleton worker allows the worker to retain that repository after its request scope has ended. It can also mix data belonging to separate users. If a singleton needs scoped work, inject an IServiceScopeFactory and create a short-lived scope at the point of use. Conversely, do not inject a transient into a scoped object unless the extra instances are intentional, because state can become surprisingly expensive or inconsistent.

ASP.NET Core creates a scope for each request, so controllers and middleware can usually consume scoped services directly. Resolve scoped services from the request’s provider rather than a global singleton. Build the provider during startup, enable data-annotation validation where appropriate, and exercise a scope in tests to expose lifetime mistakes early. This makes the registration code behave like executable architecture instead of a list of hopeful defaults.

Keeping browser and server boundaries honest

An Angular application and a .NET API usually run in separate processes, and dependency injection must respect that boundary. The browser can inject an HttpClient-based gateway, but it must never receive the API’s database context or payment service as if they were local objects. The server exposes an HTTP contract, validates it, and maps request data into application commands. This is dependency inversion at the network edge: both sides depend on a stable contract rather than each other’s implementation.

Automation follows the same rule. A server-side workflow can use Node tools to collect data, then hand normalised results to the .NET domain through a service boundary; the Angular client should call that workflow through the API rather than launching a headless browser. Steven McLintock’s scraping albums with Puppeteer is a useful example of that toolchain, with Puppeteer handling browser work and Sharp processing images. Each tool owns a capability, while the orchestration layer owns their order and error handling.

This boundary has extra weight in Australia. Banks, logistics businesses, health providers, and government agencies in Sydney, Melbourne, and regional centres often maintain established Microsoft estates, so .NET APIs and Azure-hosted services are familiar choices even when a startup’s interface uses Angular. Privacy also cannot be treated as an afterthought. Under the Privacy Act 1988 and the Australian Privacy Principles, personal information must have a clear purpose, be minimised, and be protected; the Notifiable Data Breaches scheme adds an escalation path when eligible data is lost. Injecting configuration and audit services makes those controls explicit rather than scattering them through handlers.

Testing services without rebuilding everything

Testing becomes clearer when dependencies are explicit. In Angular, configure the providers needed by a TestBed, resolve the subject under test, and replace only the boundary that would make the test slow or unstable. A component can use an in-memory gateway instead of real HTTP, while a pure service can be instantiated directly with simple fakes. Overriding a token provider is often cleaner than replacing an entire injector tree.

In .NET, construct the class with test doubles or substitute its interfaces, then reserve a smaller integration test for the real composition root. WebApplicationFactory can start the API in memory so routing, authentication, model binding, and scoped registrations are exercised together. Pure unit tests should not need a database, while a repository test can use a disposable database container or a carefully scoped local substitute.

Neither side should test an implementation detail merely because it was easy to inject. Ask whether the assertion describes observable behaviour, then substitute at the narrowest useful boundary. For a feature shared across Angular and .NET, add contract tests around the JSON shape, error codes, and authentication rules. Those checks catch the mismatch that two separately green suites often miss.

A working review checklist

A short review can expose wiring that works only on one developer’s machine. For Angular projects, check the following:

For .NET services, apply the matching review:

Finally, trace one critical user journey from the Angular screen to the .NET endpoint and back. At every arrow, name the contract, its owner, its lifetime, and its failure mode. If a value appears in several layers, decide whether it is shared business policy, transport data, or configuration. A dependency map drawn on a whiteboard can reveal ambiguity faster than another feature, especially across teams separated between Melbourne and Brisbane.

Use injection in the next feature you build

Dependency injection works best when it expresses a real boundary rather than satisfying a framework checkbox. In Angular, the injector hierarchy should make application services available without leaking framework machinery into business code. In .NET, registrations should make ownership and lifetime obvious. The two ecosystems use different tools, but both reward a small composition root, explicit contracts, and tests that can replace infrastructure at the edge.

Open the next feature you are about to build and list every external collaborator it requires. Move concrete creation into application-level providers, choose each lifetime from the state it owns, and add one test that substitutes the slowest or riskiest dependency. Run the feature through its Angular and .NET boundaries with the real configuration used for an Australian deployment, including its privacy and audit settings, before release.