Here are brief definitions of selected terms, patterns, and other concepts discussed in this book. Each definition includes a reference to the chapter where the term is discussed in greater detail.
A unifying term that encompasses both interfaces and (abstract) base classes. See chapter 2.
A DI pattern that makes a strongly typed DEPENDENCY implicitly available via a context which is always present. See chapter 4.
An approach to software that addresses Separation of Concerns by composing CROSS-CUTTING CONCERNS in a declarative manner. See chapter 9.
The ability to automatically compose an object graph once mappings from ABSTRACTIONS to concrete types are known. See chapter 3.
Use of conventions to configure a DI CONTAINER instead of using explicit registrations of each component. See chapter 3.
A DI anti-pattern. See chapter 5.
Use of imperative code to configure a module or application instead of using an external configuration mechanism, such as a configuration file. See chapter 3.
A unifying term that encompasses any object or method that composes DEPENDENCIES. See chapter 8.
A central place in an application where the entire application is composed from its constituent modules. See chapter 3.
A DI anti-pattern. See chapter 5.
A DI pattern where DEPENDENCIES are injected into the consumer as constructor arguments. See chapter 4.
The opposite of INVERSION OF CONTROL. A DI anti-pattern. See chapter 5.
Another term for AUTO-REGISTRATION.
A concern that spans multiple modules or entire applications. Typical examples include logging, auditing, access control, and validation. See chapter 9.
In principle, any reference that a module holds to another module. When a module references another module, it depends on it. Informally, the term Dependency is often used instead of the more formal VOLATILE DEPENDENCY. See chapter 1.
A library or framework that provides reusable DI functionality. See chapter 3.
Data Transfer Object. See chapter 7.
A Domain Object with an inherent, long-term identity. See chapter 7.
A default implementation of an ABSTRACTION that’s defined in a different assembly than the consumer. See chapter 5.
An object that contains little-to-no behavior itself and that instead delegates all its operations to other objects. See chapter 2.
The act of modifying a DEPEDENCY before it’s passed to its consumer. See chapter 9.
Letting a framework control the lifetime of objects instead of directly controlling them. See chapter 2.
Even though an ABSTRACTION is defined, the implementation details show through and thus lock the ABSTRACTION to the implementation. See chapter 6.
See OBJECT LIFETIME.
A software design principle that states that a consumer should be able to use any implementation of an ABSTRACTION without changing the correctness of the system. The L in SOLID. See chapter 8. See also SOLID.
A default implementation of an ABSTRACTION that’s defined in the same assembly as the consumer. See chapter 4.
A DI pattern where DEPENDENCIES are injected into the consumer as method parameters. See chapter 4.
The concept of composing applications from disparate modules. See chapter 7.
Generally speaking, this term covers how any object is created and deallocated. In DI context, this term covers the lifetime of DEPENDENCIES. See chapter 8.
This principle states that classes should be open for extensibility, but closed for modification. The O in SOLID. See also SOLID.
A DEPENDENCY lifecycle scope where we reuse a single instance across several different consumers inside the same object graph, but use separate instances in different object graphs. See chapter 8.
A DEPENDENCY lifecycle scope where we reuse a pool of prepared instances. See chapter 8.
DI without the use of a DI CONTAINER. See part 3.
A DI pattern where DEPENDENCIES are injected into the consumer via writable properties. See chapter 4.
A pattern that describes how a DI CONTAINER should be used. See chapter 3.
A place in application code where ABSTRACTIONS are used to separate modules. See chapter 1.
A DI anti-pattern. See chapter 5.
This principle states that a class should only have a single responsibility. The S in SOLID. See also SOLID.
A DEPENDENCY lifecycle scope where a single instance is reused for all consumers. See chapter 8.
An acronym which stands for five fundamental design principles: SINGLE RESPONSIBILITY PRINCIPLE, OPEN/CLOSED PRINCIPLE, LISKOV SUBSTITUTION PRINCIPLE, Interface Segregation Principle, and Dependency Inversion Principle. See chapter 9.
A DEPENDENCY that can be referenced without any detrimental effects. The opposite of a VOLATILE DEPENDENCY. See chapter 1.
The degree to which an application is susceptible to automated unit tests. See chapter 1.
A DEPENDENCY lifecycle scope where all consumers get their own instance of a DEPENDENCY. See chapter 8.
A DEPENDENCY that involves side effects that may be undesirable at times. This may include modules that don’t yet exist, or that have adverse requirements on its runtime environment. These are the DEPENDENCIES that are addressed by DI. See chapter 1.
A DEPENDENCY lifecycle scope where a single instance is reused within a single web request. See chapter 8.
18.118.37.154