Simple Injector v5
It’s been 10 years since the birth of Simple Injector, and three years since the release of Simple Injector 4.0. The number of features that mean bumping the major version number have been piling up on the backlog, and so we started work on the next major release a few months ago. And it’s finally here! This announcement on my blog is a bit late (41 days to be precise), but for anyone that missed that release, take a look at the Simple Injector blog for more information about this new major release.
In Praise of the Singleton Object Graph
To be able to achieve anything useful, your application code makes use of runtime data that comes in many shapes and forms. Providing access to that data can be accomplished in many ways. The way you provide object graphs with runtime data can affect the way you compose them using Dependency Injection. There are two competing models to choose from. This article suggests the use of the less common, more restrictive model, as it helps you reason about the correctness of the graph and reduces the chance of errors.
DI Composition Models: A Comparison
To be able to achieve anything useful, your application code makes use of runtime data that comes in many shapes and forms. Providing access to that data can be accomplished in many ways. The way you provide object graphs with runtime data can affect the way you compose them using Dependency Injection. There are two competing models to choose from. This article compares those two models. It is the fourth of a five-part series on Dependency Injection composition models.
The Ambient Composition Model
To be able to achieve anything useful, your application code makes use of runtime data that comes in many shapes and forms. Providing access to that data can be accomplished in many ways. The way you provide object graphs with runtime data can affect the way you compose them using Dependency Injection. There are two competing models to choose from. This article describes the less common model: the Ambient Composition Model.
The Closure Composition Model
To be able to achieve anything useful, your application code makes use of runtime data that comes in many shapes and forms. Providing access to that data can be accomplished in many ways. The way you provide object graphs with runtime data can affect the way you compose them using Dependency Injection. There are two competing models to choose from. This article describes the Closure Composition Model. It is the second of a five-part series on Dependency Injection composition models.
DI Composition Models: A Primer
To be able to achieve anything useful, your application code makes use of runtime data that comes in many shapes and forms. Providing access to that data can be accomplished in many ways. The way you provide object graphs with runtime data can affect the way you compose them using Dependency Injection. There are two competing models to choose from. This article introduces these two models: the Closure Composition Model and the Ambient Composition Model.
Dependency Injection Principles, Practices, and Patterns
The book Dependency Injection Principles, Practices, and Patterns has gone to print. For the last two years I’ve been coauthoring the book Dependency Injection Principles, Practices, and Patterns. This is a revised and expanded edition of Manning‘s bestselling classic Dependency Injection in .NET by Mark Seemann. I always loved the first edition as it was a game changer for me. I learned a lot about DI, DI Containers, and software design.
Simple Injector v4
For the last months we’ve been working on the next major release of Simple Injector, and it is finally here. We have removed legacy methods, simplified working with the library, and fixed many bugs and quirks. Take a look at the Simple Injector blog for more information about this new major release. Comments
Abstract Factories are a Code Smell
When it comes to writing LOB applications, abstract factories are a code smell as they increase the complexity of the consumer instead of reducing it. This article describes why and offers alternatives. TIP A more-elaborate, 14-page discussion of this topic can be found in section 6.2 of my book. The Abstract Factory design pattern decouples the creation of a family of objects from usage. Compared to injecting a service into a constructor, a factory allows objects to be created lazily, instead of up front during object-graph composition.
Dependency Injection Code Smell: Injecting runtime data into components
Injecting runtime data into your application components is a code smell. Runtime data should flow through the method calls of already-constructed object graphs. A recurring theme when it comes to questions about dependency injection is how to wire up and resolve components a.k.a. injectables (the classes that contain the application’s behavior) that require runtime data during construction. My answer to this is always the same: Don’t inject runtime data into application components during construction—it causes ambiguity, complicates the Composition Root with an extra responsibility, and makes it extraordinarily hard to verify the correctness of your DI configuration.
Dependency Injection in Attributes: don’t do it!
A number of common frameworks have promoted the concept of using attributes as a way of implementing AOP. On the surface this seems perfectly acceptable but in reality the maintainability of these options degrades as you add behaviors by injecting dependencies into attributes. The point of this article is “don’t do it!” There are better ways and this article will describe one such alternative. A long time has passed since the early formative stages of the .
Dependency Injection anti-pattern: multiple constructors
When Dependency Injection is applied correctly and completely, it is important that each type only has one constructor—multiple constructors are redundant, make your DI configuration fragile, and lead to maintainability issues. From a DI perspective, your applications have two kinds of types: newables and injectables. Newables are classes that the application news up manually using the new keyword. This is true for types such as primitives, entities, DTOs, view models and messages.
Simple Injector 2 – The future is here
Announcing the new major release of Simple Injector. The Simple Injector is an easy-to-use Inversion of Control library for .NET and Silverlight. Last week Simple Injector 2 was released. This release was a major undertaking. I’ve been working on this release full time for the last few months and I got a lot of help from enthusiastic Simple Injector users and even got a new developer on the team. I think the results are awesome.
Writing Highly Maintainable WCF Services
When it comes to writing maintainable software, there is no alternative to the five core principles of object-oriented design. When software is based on these principles, everything becomes significantly easier. When your software is based on these principles, writing a highly maintainable WCF web service on top of that can be done in just a matter of minutes. TIP The code supporting this article can be found at github.com/dotnetjunkie/solidservices.
Primitive Dependencies with Simple Injector
This article describes how to extend the Simple Injector with convension-based configuration for primitive constructor arguments. UPDATE April 2017: For a version compatible with the latest version of Simple Injector, please go here. When working with dependency injection, services (classes that contain behavior) depend on other services. The general idea is to inject those services into the constructor of the consuming service. Primitive types are no services, since they contain no behavior, and I normally advice not to mix primitive types and services in a single constructor.
Returning data from command handlers
This article extends the architectural design of command handlers to allow command handlers to return data. UPDATE Although the article below might still be very entertaining, my opionion on the subject has changed. The problems described below will go away completely when you stop using database-generated IDs. Instead let consumers of that command generate an ID (most likely a GUID). In this case—since clients create the ID—they already have that value, and you don’t have to return anything.
Meanwhile... on the query side of my architecture
Command-query separation is a common concept in the software industry. Many architectures separate commands from the rest of the system and send messages that are processed by handlers. This same concept of messages and handlers can just as easily be applied to the query side of an architecture. There are not many systems using this technique and this article is an attempt to change that. Two simple interfaces will change the look of your architecture… forever.
Meanwhile... on the command side of my architecture
This article describes how a single interface can transform the design of your application to be much cleaner, and more flexible than you ever thought possible. TIP Chapter 10 of my book contains a much more elaborate version of this article. Since I began writing applications in .NET I’ve been separating operations that mutate state (of the database mostly) from operations that return data. This is basically what the Command-query separation principle is about.
Adding Covariance and Contravariance to Simple Injector
A few weeks back I read this question on Stack Overflow. The question was about applying covariance / contravariance (or variance for short) to the Autofac dependency injection container. The question triggered me to think about variance support in Simple Injector. I was wondering whether special changes were needed to the core framework to allow this. However, it didn’t take me long to realize that enabling variance is actually pretty easy for anyone using the Simple Injector.
Dependency Injection in ASP.NET Web Forms
This article describes how to create and configure a custom PageHandlerFactory class that enables automatic constructor injection for System.Web.UI.Page classes. This keeps your application design clean and allows you to keep the application’s dependency to the IoC library to a minimum. IMPORTANT: Since the introduction of Web Forms v4.7.2, there is now better support for DI. That makes this article out-dated. When working with IoC frameworks, one should always try to minimize the amount of application code that takes a dependency on that framework.