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. An Abstract Factory decouples the creation of a family of objects from usage. Compared to injecting a service into a constructor, a factory allow objects to be created lazily, instead of up front during object graph composition. Many applications make use of the Abstract Factory pattern extensively to create all sorts of objects.
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. rom a dependency injection perspective, our 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. The code supporting this article can be found at github.com/dotnetjunkie/solidservices. Most of my clients have maintainability issues with their software.
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 Simple Injector v4 compatible version of these code samples, please see 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 use database generated IDs! Instead let the consumer of that command generate an ID (most likely a GUID). In this case, since the client creates 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 command messages that are processed by command 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. 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.
Breaking changes in SmtpClient in .NET 4.0
In .NET 4.0 the SmtpClient class now implements IDisposable. This is a breaking change what you should watch out for. For .NET 4.0 the BCL team decided to pool SMTP connections, just as .NET already did with database connections. This of course means that the SmtpClient class should implement IDisposable, just as the SqlConnection does. When STMP connections are pooled, the overhead over establishing a new connection is lowered, which is a good thing.