Mark Seemann - Dependency Injection in .NET

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 261 Shelter Island, NY 11964 Email: orders@manning.com

2012 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Mannings policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

Manning Publications Co.20 Baldwin RoadPO Box 261Shelter Island, NY 11964

Development editor: Cynthia Kane Copyeditors: June Eding, Tiffany Taylor Proofreader: Katie Tennant Typesetter: Dennis Dalinnik Cover designer: Marija Tudor

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 MAL 17 16 15 14 13 12 11

To Cecilie

I couldnt have done it without you

My first experience with Dependency Injection was almost 10 years ago. I was working at an ISV (independent software vendor) as an architect on an enterprise framework building LOB (line-of-business) applications. In those days, it seemed like all my friends in the industry were building similar frameworks. The framework supported various layers across n-tier applications addressing data access, business, and UI concerns. The product-supported business objects could be persisted across multiple databases and represented in multiple UIs; the challenge was finding a way to build the system to make it extensible and maintainable. We found our answer by wading into the waters of Dependency Injection. Using a DI approach, we clearly defined contracts for the layers, allowing us to more easily test the layers as well as to swap their implementations without breaking the code.

Mark talks quite a bit in this book about poor mans DI and this is exactly what we were doing. In those days, we didnt have DI containers at our disposal. We also didnt have the type of guidance youll find in this book. As a result, we made a lot of mistakesmistakes you wont have to make.

In the past four years, Ive personally worked with hundreds of customers and Im aware of thousands that have found success using the techniques described in this book.

It all starts with patterns.

DI containers are just tools. The tools are only useful if youre building systems that incorporate the patterns that the tools are addressing. They arent the solution to every problem. Ideally, you need to first learn what Dependency Injection is, what kinds of problems it solves, and what the patterns are for using it. Then you can look at the various tools as aids in applying those patterns.

This book will help you with all of the above. The early chapters present an overview of the general problems that occur when software is tightly coupled. The book then discusses ways we can apply various techniques, both simple and advanced, to address those problems. Along the way, the book classifies various patterns and identifies when they are most appropriate for specific situations. In the second half, the book presents a comprehensive overview of the most common DI containers/frameworks in .NET and explains how to use them to apply different techniques.

With this book, you will benefit from the knowledge of someone who has many years of real-world experience in applying these techniques. This is a real treat; often, those who start using DI quickly find themselves lost in a sea of confusion. This book addresses any potential misunderstanding, starting with basic questions like, Where should I put my IoC? or Should I expose my container? Mark covers these questions and many more.

Throughout the book, Mark not only describes the techniques but really goes into depth explaining when you shouldand, more importantlyshouldnt use them. When he describes a problem, he uses realistic examples to keep the big picture in focus.

If you are new to IoC, I believe youll find Dependency Injection in .NET to be a great resource for learning. Even if you have extensive experience with IoC, youll still benefit from the painstaking work Mark has done to classify various patterns and create a taxonomy for IoC. I also think that you will find his comparisons with other IoC containers beneficial.

Regardless of your level of experience, I wish you success with this book.

GLENN BLOCK

SENIOR PROGRAM MANAGER

MICROSOFT

Theres 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 youre 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, youre 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 yearsand 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 cant recall any of the Microsoft product sessions I attendedbut 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 didnt 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 couldnt 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.