Preface

There’s a peculiar phenomenon related to Microsoft called the Microsoft Echo Chamber. Microsoft is a huge organization and the surrounding ecosystem of Microsoft Certified Partners multiplies that size by orders of magnitude. If you’re sufficiently embedded in this ecosystem, it can be hard to see past its boundaries. Whenever you look for a solution to a problem with a Microsoft product or technology, you’re likely to find an answer that involves throwing even more Microsoft products at it. No matter what you yell within the echo chamber, the answer is Microsoft!

When Microsoft hired me in 2003, I was already firmly embedded in the echo chamber, having worked for Microsoft Certified Partners for years—and I loved it! They soon shipped me off to an internal tech conference in New Orleans to learn about the latest and greatest Microsoft technology.

Today, I can’t recall any of the Microsoft product sessions I attended—but I do remember the last day. On that day, having failed to experience any sessions that could satisfy my hunger for cool tech, I was mostly looking forward to flying home to Denmark. My top priority was to find a place to sit so I could attend to my email, so I chose a session that seemed marginally relevant for me and fired up my laptop.

The session was loosely structured and featured several presenters. One was a bearded guy named Martin Fowler, who talked about Test-Driven Development (TDD) and dynamic mocks. I had never heard of him and I didn’t listen very closely, but, nonetheless, something must have stuck in my mind.

Soon after returning to Denmark, I was tasked with rewriting a big ETL (extract, transform, load) system from scratch, and I decided to give TDD a try (it turned out to be a very good decision). The use of dynamic mocks followed naturally, but also introduced a need to manage dependencies. I found that to be a very difficult but very captivating problem, and I couldn’t stop thinking about it.

What started as a side effect of my interest in TDD became a passion in itself. I did a lot of research, read lots of blog posts about the matter, wrote quite a few blogs myself, experimented with code, and discussed the topic with anyone who cared to listen. Increasingly, I had to look outside the Microsoft Echo Chamber for inspiration and guidance. Along the way, people associated me with the ALT.NET movement even though I was never very active in it.

I made all the mistakes it was possible to make, but I was gradually able to develop a coherent understanding of Dependency Injection (DI).

When Manning approached me with the idea for a book about Dependency Injection in .NET my first reaction was, Is this even necessary? I felt that all the concepts you need to understand DI were already described in numerous blog posts. Was there anything to add? Honestly, I thought DI in .NET was a topic that had been done to death already.

Upon reflection, however, it dawned on me that while the knowledge is definitely out there, it’s very scattered and uses a lot of conflicting terminology. Before this book, there were no titles about DI that attempted to present a coherent description of it. After thinking about it further, I realized that Manning was offering me a tremendous challenge and a great opportunity to collect and systematize all that I knew about DI.

The result is this book. It uses .NET and C# to introduce and describe a comprehensive terminology and guidance for DI, but I hope that the value of the book will reach well beyond the platform. I think that the pattern language articulated here is universal. Whether you are a .NET developer or use another object-oriented platform, I hope that this book will help you be a better software engineer.