When wiring a web framework's container, when do you register a dependency by type, by name, or with a factory?

## Every registration answers three questions When you add a service to a container you are answering: **under what key** will it be found, **how** is it built, and **who chooses** when several candidates could satisfy the same key. The three common registration styles are three different answers to those questions, and mixing them badly is where wiring stops being mechanical. ## Registering by type The default style binds an **abstraction to one implementation**: requests for the abstraction resolve to that implementation, and any constructor parameter typed as the abstraction is filled with it. Nothing at the injection site has to say anything — the parameter's type *is* the request. This is the style to reach for whenever the answer to "which one?" is "there is only one". It keeps consumers free of wiring knowledge, which is the property that makes a graph easy to re-point later. Its failure mode is **ambiguity**: register two implementations under one abstraction and resolution has no rule to pick between them, so most containers fail rather than guess. ## Registering by name or key Sometimes two instances of the *same* type are genuinely different things: a connection to a primary store and one to a replica, an outbound client aimed at one partner and another aimed at a second. The type no longer identifies them, so registration adds a **discriminator** — a name, a key, a qualifier — and the injection site must state which one it wants. The tradeoff is explicit: you have bought the ability to have several, and paid by pushing a wiring detail into the consumer's declaration. A named binding is also the one style where a typo produces a missing binding at resolution rather than an error a compiler could have caught, so names are worth defining once as constants rather than spelling out at each site. ## Registering with a factory A factory registration hands the container a **function to call** instead of a constructor to invoke. Use it when the container cannot work out the arguments by itself: - construction needs **values that are not services** — a timeout, a base address, a feature flag read from settings; - the implementation is **chosen at wiring time** by inspecting settings or the environment; - the object is produced by a builder that must be configured step by step before it yields the instance; - the instance comes from somewhere else entirely — a pool, a cache, another library's entry point. A factory receives a handle to the container (or its own injected parameters) so it can resolve what it needs and then apply the non-service arguments itself. The cost is opacity: the edges of the graph now live inside a function body, so the container can no longer report them, and a graph-validation pass cannot see through them. ## Choosing between them | Style | Use when | Injection site says | Main risk | |---|---|---|---| | By type | Exactly one implementation satisfies the abstraction | Nothing — the type is the request | Ambiguity if a second is added | | By name or key | Several instances of one type are different things | The name it wants | Typos fail only at resolution | | By factory | Construction needs non-service values or a runtime choice | Nothing extra | Hidden edges, harder to validate | ## Registering several implementations on purpose A fourth case is worth separating from ambiguity: sometimes you really do want **all** of them. Many containers let several registrations share one key and inject the whole set as a collection, which is how pipelines of validators, notification channels or format writers are assembled. The consumer takes a collection rather than a single instance, and adding a behaviour becomes one registration with no consumer edit. Ordering across such a set is rarely defined by the container, so when order matters, express it in the registration or sort explicitly inside the consumer. ## The failures each style produces 1. **Missing binding** — nothing is registered under the requested key, or a name is misspelled. 2. **Ambiguous binding** — two recipes share a key that expects one answer. 3. **Silently wrong instance** — two same-typed services registered without discriminators, where the container happily resolves the last one registered; this is the dangerous one, because it starts successfully and misbehaves at run time. 4. **Unresolvable factory argument** — the factory asks the container for something that was never registered, which surfaces only when the factory runs. A practical rule: prefer **by type** until a second implementation genuinely exists, add a **discriminator** the moment two same-typed instances mean different things, and keep **factories** for the arguments a container cannot invent.