Dependency Injection in .NET

This is the only technical book that I've purchased multiple times. I keep loaning it out to teammates encouraging them to read it, losing track of it (or, more likely, them not wanting to give it back), needing it again, and then the repurchasing cycle continues. The principles have really altered my approach to programming and problem solving in general, and I've been able to save incredible amounts of time and effort by implementing dependency injection and utilizing the flexibility that comes with it. I've used these principles over the last 5+ years on multiple projects and keep coming back to this book and finding new nuggets of helpful information. Mark explains the ideas and motivations incredibly well. This book should be required reading for every developer, and is worth its weight in gold.That may seem like hyperbole, but it's really not - I would not have been able to meet tight deadlines for many of the projects without- being able to easily test code to find bugs early (the later in the process that a bug is found the more expensive it is to fix) (TDD and Liskov Substitution Principle)- being able to build up an toolbox of small chunks of code that do a single thing well and can be composed into different things quickly depending on what I need at the time- being able to quickly react to changing requirements by swapping out different dependencies (paying attention to where the composition root should be)- being able to add cross-cutting functionality without modifying existing code modules (decorator pattern)- being able to "make things fit" (adapter pattern)- being able to manage project risk by hiding dependencies on other people's code (whether open-source, another team in the company, etc) behind seams/interfaces in the right place

The book does a good job explaining dependency injection in the context of .Net and for that I'm thankful. I've read about half the book so far and I've learned a lot but I can't say that I'm convinced yet that DI is a step forward for software development, or that I intend to use it.While the author claims that testing is only one of many benefits to DI I don't believe the book bears that out. As a seasoned developer I can't help but ask, if 40% (my estimate) of the code written by developers is to verify that their app works correctly (unit tests) shouldn't one seriously question the appropriateness of the software architecture chosen? I'd much rather see that time go into making abstract software development constructs much more concrete so that future maintainers of the code base can follow what's going on. The hardest part of software development is taking mountains of abstract ideas and creating concrete manifestations of them. Dependency injection does nothing to tackle that problem. In fact is coaches that the developer should code everything to interfaces and keep connections between classes as abstract as possible. At the very least I'm skeptical that such an approach decreases the lifetime cost of the software or decreases the time necessary to adapt the code to new uses.My hope is that the dependency injection fad doesn't last much longer than the XML/SOAP fad.

The Short Story: This is the best software development book I have ever read. By miles. Or, in deference to Mr. Seeman, in kilometers. Stop. Buy this book. It will change how you think, how you reason, how you sleep at night. See you in a year, we will both be smarter.The Long Story: I bought this book last year. I can't remember exactly why I bought it, but I suspect that it had something to do with intellectual intimidation and the frightening title. I come from a non-OO background, but I am too young to get through the next 20 years without dealing with the reality of OO prevalence in small (i.e. numerous) projects. I had 2 choices ... start at the bottom or start at the top. Believe me, I chose the latter with this book.I'm not going to explain the content in every chapter, simply because other reviewers have already done the job as I would have. Read Mr. T. Anderson's fine review if you need that kind of detail. Instead, I will talk about the effect that this book had had on how I think.Chapter 2 is the velvet sledgehammer in the face. I read along with the case study, nodding my head and exercising my (in retrospect, tiny) brain as Seeman describes how "Mary" and "Jens" go about building a layered application. I'm thinking, yes Mary and Jens, this is what the magazines, blog articles, and dime-a-dozen gurus are saying regarding the construction of layered application. Seeman then dissects the "layered" application. Actually, he doesn't dissect it; he tears it to shreds and stamps all over it. Brilliantly. It's truly scary to read this chapter. You will feel like a complete novice at the end of it. You then have two choices ... (1) reject this stuff as abstract, ivory tower nonsense, or (2) put on your big-boy-pants.Having lived with this book for almost a year, this is how I suggest you use it:1. Read from Part 1 through Part 3.2. Stop. Think. Cry at how embarrassed you feel at the end of Part 1 Chapter 2.3. Read Part 2 again.4. Stop. Think. Cry at how happy you feel now that you've lifted yourself beyond 99% of .NET developers. Beyond 99% of software professionals, period.5. Do some "poor-man's DI" exercises.6. Read only the introductory sections of each chapter within Part 4.7. Pick a DI container in Part 4 that appeals to you based on the previous bullet, read its Part 4 chapter, and spend 1-2 months playing with it.8. Revisit Parts 2 and 3 on a regular basis as references.9. Don't think about sauces or Fowlerisms.Criticisms: Very, very, few. I do not think it's too "wordy" at all. Any repetition is done with the realization that this stuff is really, really, hard for most of us. But yes, any mention of nonsense about "Anemic Domain Models" normally sets my blood boiling and warrants an immediate docking of at least 1 star. I can't dock a star from this book. It's that good. It's written by a mildly (but not offensively) dogmatic Danish guy who talks about sauces in every chapter. I like my Filets Mignons dry, thank you very much. And still, at the end of the day ... this is best software development book I have ever read. By far. By miles. By kilometers ...

I'm only at 100 pages and I've learned so much already.It's well written so easy to read. Examples are self-explaining and I'm enjoying the book so far!

Dieses Buch war für mich eines der nützlichsten Bücher über Software-Entwicklung, die ich je gelesen habe. Es räumt mit Mythen über DI auf und zeigt im Detail die Anwendung dieser Technik und geht auch auf speziellere Problemfälle ein. Mir gefällt, dass es ein so umfassendes Buch ist, was sowohl Theorie als auch Praxis abdeckt. Verschiedene Aspekte von DI werden diskutiert. Insbesondere finde ich gut, dass an vielen Stellen Sachen wiederholt werden und and vorherige Kapitel erinnert wird. Viele Ideen konnte ich sofort in einige Projekte übernehmen, wenn auch die Technik eines kompletten Refactorings bestehender Applikation bedürfen kann. Man kann sich darüber streiten, ob das letzte Kapitel des Buches weggelassen werden kann und man lieber ein spezielles Buch für einen speziellen DI Container ließt. So ist es aber gut zu sehen, wie unterschiedliche DI Container bei denselben Problemen anzuwenden sind, bzw. eines diesen an Features fehlt. (Dabei muss man das Alter des Buches beachten). Ein Vorteil des Buches ist, dass ein Großteil nicht von bestimmten DI Containern abhängt, sonder mit Poor Man's DI beschrieben wird und somit eine Allgemeingültig besteht.

Questo è un testo che per me ha segnato una svolta nella progettazione del software.La descrizione dei vari container di dependency injection disponibili per il framework .NET è esaustiva, ma non è la parte "di valore" di questo testo.Quello che questo libro riporta è una visione illuminata di come la gestione delle dipendenze DEVE essere applicata in progetti software complessi, indipendentemente dal fatto che venga utilizzato un container di dependency injection o meno.Evidenzia come sia facile sbagliare la struttura architetturale di base delle applicazioni enterprise fornendo degli esempi "reali" perfettamente plausibili.Mostra come definire correttamente ogni "bounded context" in pieno spirito DDD.Descrive gli antipattern più subdoli ma così comuni nella maggior parte delle architetture software esistenti.Insomma, vi farà passare al livello successivo come programmatori e architetti .NETMolto probabilmente, dopo aver letto questo libro guarderete le vostre applicazioni delle quali adesso siete così fieri e vi sentirete degli incapaci (come è successo a me).Grandissimo Seemann: grazie per questo testo.

Must Read Book for Software Developers. Read with GOF.

Fantastic explanation of Dependency Injection. This book has completely changed the way I program. The book was clear with great examples.