End-to-End Dependency Injection & Writing Testable Software
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Castro, Miguel A.
Dependency Injection is one of those terms that advanced programmers throw out with an expectation and assumption of full understanding on the part of the receiver. However, I constantly get asked by attendees, students, and clients to please recommend a good DI product and show them how to use it; and when I proceed to start talking about the subject, it becomes immediately apparent that many don't even know what they're asking about. It's easy to get infatuated by a cool buzz phrase, specially when you hear so many others using it. But to truly understand something you need to start by understanding the problem spaces that it is trying to solve. It’s important to learn the concepts behind DI so you can write software that can be properly tested. So let's bring you totally up to speed then. In this session, I'll explain dependency injection from concept to implementation, and use raw code samples to show you how it works and what problems it solves. I’ll demonstrate how writing abstracted code can help you test your applications much better, whether or not use a DI container. Then I'll get into what a DI container is and some of the characteristics and features it offers. I’ll finish by showing you implementation examples in three different platforms.
 I don't do Q&A at the end of a talk. If you have a question, just raise your hand and ask me in the middle of it. I don't want you to lose your train of thought in asking a question, so I don't make you wait till the end. I'll be repeating the question so we can have it on the record since this whole thing is being filmed and recorded. And welcome to DI. So I want to ask a question because I'm going to anticipate what you guys may not ask, but I usually get this asked by a lot of other speakers. People will approach me and say, why are you still talking about DI? Everybody's doing that. And I don't know about Europe because it's a very, very different audience, but how many people here use dependency injection mainstream in all their applications at work in the projects they're working on? You see? A handful of you, probably less than a quarter of you. In America, an audience of this size, I get two or three people that raise their hands. And it's really a sad thing because that's the whole reason why I still talk about this subject. This is one of those things that needs to become mainstream. It's a very important part of software development today, and it's not rocket science. It's not difficult to do, and the benefits are huge. There was a time several years ago where dependency injection and version control, containers, all those kind of, that kind of lingo was what the cool kids were doing, right? It was the buzzwords. And everybody wanted to do it because it just sounded really cool, and I know that's what the experts are working with. It's not like that anymore, and it shouldn't be like that. It shouldn't have been like that back then. This is something that's important, and that should be part of all of our software development. What's going on with that thing? Am I supposed to avoid that section? I don't know. All right. So, what we're going to talk about is the difference between coupling and non-coupling. Now, some of the stuff that I am going to go over, you may already be familiar with, but I do things in a step-by-step process because I'm going to build up to the actual usage of DI. This talk is supposed to be a 75-minute talk, but in NDC, they only do 60 minutes. So, you're going to find me rushing through a couple of things. I'm going to try not to rush. What I'm going to do instead is there's a section at the end here. What is going on with this thing? What was that? Did you say post back? This freaking thing was written in web forms. Is that what you're saying? So, I go through the explanation of the dependencies and what coupling is and how with coupling, you don't have testing. I'm going to go through that and get into decoupling and why testable software is very important and what is the basis for testable software. Then I'm going to get into dependency injection because the truth of the matter is that in order to use dependency injection, you have to set the groundwork for it. The groundwork comes in making your software testable. If you can get to that point and abstract enough to make your software testable, you've accomplished more than your average developer, at least in the states, which is a sad statement for me to make, but that's the God-honest truth. Then from there on, DI can help you take it to the next level. Now, I'm going to go through all of this because I use AutoFac, by the way, in my examples, but I do have code samples for you to take with you that are in all the other containers, probably four or five other containers, including MEPH. But AutoFac is my container of choice. The area here is what I may or may not get to, depending on how we do with time. What this is, they're four complete working examples of dependency injection usage in all these four types of applications, including a webforms applications for this post-bac guy right here. You got some real good real-world usage scenarios there that I will try to get to, but I'm not going to guarantee it because of the fact that I only have one hour. All of this starts, this thing is flickering, by the way. Every once in a while, it just kind of flickers. Let's see if it's not going to do it. It's like bringing your car to the mechanic. It doesn't reproduce the noise, so it's not going to reproduce it now. The idea of writing testable software involves breaking this lifelong habit. The lifelong habit involves class coupling. I'm going to get into that. I'm going to go back to that statement in just a second. Coupling very simply, as I'm sure a lot of you know, is just one class depending on another. The class cannot exist, cannot function, most of the time it can't compile without some kind of partnership class, some kind of partner class. This has a lot of limitations. The first one is that it limits you to single implementations because you got one concrete class depending on another. For example, you got one class that performs database work in your data access layer. You got a business engine class that calls upon that. Those things are very tightly coupled. If they're very tightly coupled, it becomes difficult to test. The reason it becomes difficult to test is because you can't write a unit test against that business engine class without it hitting your database, which is not something that you want to do in a conventional unit test. That's something that you reserve for what we call integration tests. This kind of coupling where we have concrete classes depending on one another is generally bad. Now, why is it bad? Well, the answer to that question is in the secret to writing testable software, which is that breaking a lifelong habit that I told you about, and that is stop newing up objects inside a class. Now, my general experience with European audiences is that they're a little more advanced than a lot of audiences that I speak to in the States. I don't know what the reason for that is. I don't think it's because your skill level is higher than American programmers. I think it's because American conferences attract primarily newbies. At least that's been my experience. When I make a statement like this in front of 100 people that are just got into programming two or three years ago, it's usually a shock and awe statement. What do you mean stop newing objects in class? How else do you expect me to instantiate an object? Well, there are other ways of doing it. The first step to writing testable software is to embrace abstractions, and you do that by using interfaces quite a bit. This gets, I get fight back on this statement quite a lot because people tell me, well, that's why I don't like to code that way because I end up with almost an interface for every class. Yeah, you kind of do. That's not a bad thing. There's nothing wrong. We're programmers. We like to program. We like to write code. Why are we trying to get out of the idea of writing code if it's the right code to write? Having an interface for most, if not all of your classes, lets you pass these interfaces around. This limits the coupling massively because now one class does not depend on a concrete instance of another one. It depends on an abstraction, a definition of it. Now that definition can vary depending on the scenario. The production world, the definition of a class that gets used by another is one implementation in a testable scenario, in a test world, it may be a different implementation. Let's go back to that example about the data access layer class. You have a concrete implementation to production that uses entity framework and system data, ADO.net, all that fun stuff to actually access SQL server. But in the testing scenario, you can use a test version of an interface, so it's a different class. It's got the same create, read, update, delete, same methods that normally go to the database, but they do something else that don't physically hit a database. Now by passing that implementation into another class, you've just made that class extremely testable. This is going to make a lot more sense when I show you code. Actually, I'm going to show you code right now. How about that? I guess you guys rather stay in PowerPoint. What do you prefer? All right. Where is – so this is a very simple coupled example. I'm just going to go through it really – it's stupidly simple because all I have here is I have a commerce class that's got a method called process order. The commerce class has broken out the idea of processing a customer's order into four different steps. One of them is to update the customer database. The other one is to run the customer's credit card. Another step is to log the information to like an audit log or something. The other one is a notifier step which sends out an email to the customer saying, thanks for your order, here's your receipt. I got these steps broken out into four different classes. All the steps you're doing is writing out to the console, so obviously you're not doing anything crucial. This is where you would process a customer's credit card. This is where you would write out product and customer purchase information to an actual database. This is where you would use, let's say, log for net or something to write out to an audit log that may go to either a text file or a database. This one is going to access system.mail to actually send out an email. All of these have pretty concrete implementations of what they're supposed to do and the kind of implementations that you don't want to run over and over again if you were testing this class. If we're running all four of those steps from this commerce class here, the commerce class is going to rely on those four helper classes. As you can see, they're completely tightly and very poorly coupled to the commerce class because they're being instantiated right here. If I'm going to instantiate this class in a unit test scenario, I'm going to have the exact same effect as if I'm running it in production. That's not what I want. I want to access the database from here. I don't want to send out an email every time that a unit test is run. This is a perfect example of just some really poor coupling. How does this get fixed? Very, very easy, actually. If all of these classes have a corresponding interface that defines them, in this case, iBuildingProcessor defines this one, as you can see, it's just a quick definition. The other four, which I won't bother showing you, are exactly the same. They just have a corresponding interface. Now that's what's being used here. Now as you can see, I can instantiate the commerce class and send in instances of these classes during production. The beauty of this technique now and why it's considered testable is because now from a unit test, I can decide what I want to send into here that does not actually perform those concrete steps. It does not send out a physical email or notify the client, does not update the database, and certainly does not process a credit card. Can you imagine that concrete step being run over and over again in a unit test? That's not what we want. In a testing scenario, we would like to set up test versions or test implementations of each of these interfaces. That becomes a whole lot of work. That's usually one of the reasons why I get pushed back from people. Well, if I have an interface, now I've got to have a production implementation, I've got to have test implementation. First of all, yes you do. That's just good coding. It's good programming to have two different implementations, one for production, one for test. It's an easy way to get the test done that I'm sure at least some of you in this room have done something with. Has anybody worked with the mocking framework before? All right, quite. You see, more people than have worked with the DI container. How about that? That's weird, to be honest with you. So this is an example of using a mocking framework. I don't know what Visual Studio does, those retarded things once in a while. It just stops. You ever get the general message from Visual Studio saying I'm busy? Visual Studio is busy. Is that rude or what? I got shit to do. Don't tell me you're busy. All right, so this is an example of using Mach Q. Now, I'm not going to go through a tutorial on Mach Q, but just to show you what I've done here is that ultimately I need to instantiate my commerce. But obviously my commerce class needs four instances of each one of those objects, those implementations of those four interfaces. What a mocking framework allows you to do for those of you that have never seen it before is create a test version of an interface, a test implementation of an interface, but do it all at runtime. And depending on how the mocking framework is written, the language is just going to vary a little. Here, all I'm doing is that I'm creating an object that's a mock of iCustomer. Then I am taking mockCustomer and setting it up. And what you can do in the setup here is a ton of different things. I'm keeping it very simple. I'm saying whenever you call updateCustomerOrder with any string and with any string, don't do anything else. But if customer order happened to return something, I can then do a returns here and return whatever the object is that it needs to return. If I wanted to set up this mockCustomer so the updateCustomer works only if this string is something specific and this string is something specific, I can set it up that way. Once I have my whole mock set up, I can just address it as mockCustomer.object. And this type right here is actually an implementation of iCustomer. So the mocking framework should definitely be in your toolbox as you start writing testable software, as you start writing software that is geared for testability. Very important. And now I can run this unit test. And remember the idea of the unit test is to test that process order, complete it without exception. It's not the test that process order updated the database, send out an email and process a credit card. That's an integration test. I just want to make sure that that unit complete it without exception. And I can do that by sending these mocks into there. So very, very simple process. Now if I go out to here, you notice that this class cannot work, cannot instantiate without four implementations of these dependencies, these dependent classes. So something has to instantiate these classes and send them in. Obviously whatever the caller is. Now this is where the use of a product helps us a lot. And that's product is known as a dependency injection container. I'm not here to push any product. I happen to like AutoFact because it's what I use and it's easy for me to use. But use whichever one you're familiar with. Anybody use Castle Windsor here? Okay, three people. Structure map? Two, three. Ninja. Couple more. Unity. I'm sorry. What about AutoFact? Okay. They're all good. The language for them is just a little different, that's all. AutoFact happens to be the, I think it's the newer one. So it was written in.NET 4 or 3.5 or 4, so it's one of the newer. But they all do, you know, these guys that wrote these containers are very competitive with each other. So, you know, if one guy adds something to Castle Windsor, then Jeremy who wrote structure map immediately goes and puts out an update for structure map to compete with what Castle Windsor just received. So they're all going to do very, very similar things. It's a dependency injection container that is going to not only take care of injecting these dependencies into this class, but is also going to eliminate that rule that I told you earlier that I said was usually a shock on our rule of not newing objects up. Because something has to new it up, right? If this class is not going to new up these classes, which we don't want it to, then whatever calls commerce is going to be newing up these classes and sending them in. But we're going to eliminate that as well. And we're going to do it in a very cool way, because I'm going to show you how recursively we can go as low as we need with one class calling another, calling another, calling another, and let the dependency injection container take care of everything for us. Let's go back to the slides real quick. So dependency injection in general is just a pattern. It's an architectural pattern that's designed to satisfy the dependencies in a class. You just saw an example of one class with four dependencies. It helps us resolve the dependencies when we wrote our code in a very decoupled way. So we're going to do that without having to worry about instantiating those dependencies from any level in our object chain. We eliminated the instantiation from that commerce object, but like I said, something has to instantiate it. Well, we're going to actually eliminate that as well. You're going to see how cool it's actually going to be. So this pattern gets a lot of help with the help of this product, this product known as a container. Another term for dependency injection containers and inversion of control container, the terms are kind of used interchangeably. Put simply in its basic form, a DI container, as I'll call it going forward, is all about two things, registration and resolve. A DI container will have a registration phase at the beginning of an application done once only. If it's a web app, it's done in the global ASAX or a class that's called by global ASAX. If it's a WPF or WinForms or some kind of desktop app, it's done at the beginning of app load probably while the splash screen is loading, but it only needs to be done once. And the container itself is held on to class wide, statically, typically. And all registration is the association, the building of a list of key value pairs associating a class to an interface. In its simplest form, I say simplest form because there's a couple of things that I'm going to throw in there that are going to complicate it a little more, but that's good. I suspect you guys are not newbies, so a little complication in your life, especially when it comes from an American, is a good thing, right? That was supposed to be funny. Laugh a little. We're on the record. It's being recorded. Laugh into the microphone. All right, so it's about building a bucket of key value pairs. I hesitate to use the word bucket list because it's very morbid, but it's a bucket of key value pairs associating one class to an interface. This is what's called, this is registration. So in the examples that I showed you, the building processor class is associated with the iBuildingProcess interface, the logger class with the iLogger interface, and so on. And some of these registrations can get really, really long. I've been known to register 200, 300 different classes for a large project. Every container has multiple ways of doing its registration. Most of them now support all of these things. The most common way of doing it is procedural, which means you're going to see an actual code statement that registers, register this class to this interface. But there's ways of storing those associations in a config file. There's ways of doing discovery. Mef does it through discovery, where you tag classes with an attribute, and that attribute relates it to the interface. So later, Mef goes out and discovers everything in your types with who's using this attribute, and this is how I can tell that this is the interface that you're using. So there's multiple ways of doing it. We're going to stick with the procedural way in our examples. The second thing that the container is used for is the resolve process, and that is when the need for a dependency is encountered. And I'll go over the detail on when that is. But when that need is encountered, the container will say, OK, I have a property or an argument or something here that's a type iBuildingProcessor. Let me go into that bucket list that you created during registration and figure out what is iBuildingProcessor associated to. Ah, it's the building processor class. Let me new it up and inject it into that constructor. And that's how the container is going to take care of us not having to new up objects anymore. But this is where it gets really, really cool, because it kicks off a chain reaction, a DI resolve chain reaction. So let's go back to that example again. You saw the commerce class relying on four constructor arguments of four interface types. When that commerce class is created, and it's going to be created by the container, the container is going to resolve it. The container is going to use reflection, and there's reflection involved here, so get over it. If you have a fear of reflection, get over it. Reflection is not as heavy as people think if you used right. The container is going to take that commerce class. It's going to reflect into it. Look at the constructor and see that it's expecting four interface types. Now before the container can new up the commerce class, it knows that it needs to instantiate those four classes so that they can inject them in there. So it's going to go to each one. So it starts with the building processor. It goes back into its bucket list and says, OK, I building processor is associated with the building processor. So before it news up building processor, guess what it does? It goes into the building processor class, looks to see if it's got any dependencies in its constructor. If it does, it performs the exact same process. When it finally gets to a bottom of the chain where it has no more recursion, no more dependencies to resolve, it then says, OK, now I'm ready to new this class up. Take the instance of that and inject it into this one. Finish the dependencies for this one. Once this is done, new this one up, inject it into this one. Finish the dependencies here. And it keeps doing that back up the chain until it gets to the original host that asks for the commerce class. What this means is that this class right here has only four dependencies. However, this class has no dependencies, but I commented out some code here that I did for the previous session that I did at the previous conference where this building processor had a dependency for a data repository to access the database. If that interface, iDataRepository, is registered to an actual data repository class with my container, then when the container goes to resolve this here, when it sees this, it hasn't instantiated this yet. It's still in the reflection phase. When it sees this, it says, OK, let me go into this one and new it up. Oh, hey, I can't new this up yet. It's got a dependency. So let me go into here. What is this registered to? A data repository class. Does this have any constructors? Nope. This one doesn't. No dependencies. So let me new up the data repository, put it into there. Now there's no more dependencies. I can now new up building processor. Now I have a class that I can inject right into there. This is the container talking. I can inject it into there onto the next one, and it performs the same process for the next one. The beauty of this is that once you have all of your classes in your project registered with a container, you can start using class. I made the decision to add the dependency of idata repository to building processor later in my project. Perhaps I had data access stuff in here, hard coded into here, for whatever bad reason, because I was a poor programmer. I just had pure ADO.NET in here. I didn't like it. I refactored it into a data repository class. And then what do I have to do to add that to building processor? All I got to do is add it as a constructor there. The container will take care of instantiating it for me. It's a very, very nice solution. If I didn't have the container, but I went ahead and I did all of this decoupling, I've gone halfway. I've gone a very good way, because I've written testable software. By getting just to the point of embracing these abstractions and working with these interfaces, you're writing testable software. You're doing things much, much better. But you're also doing things a little harder. You're making it harder for yourself, because now, yes, I'm able to test these classes because of the abstractions. But now, whatever is instantiating building processor has to inject that in there manually. And if that something is up here, well, I don't want to knew it up in here. So now, whatever is installing this has to inject, has to knew up building processor, and in turn, has to knew up data repository, and have knew of this, knew of this, knew of that, and then knew up commerce with the string of constructors. And it just becomes a lot more difficult. You're going to see how easy it is when I show you the DI code. Everybody got a pretty good idea of what I'm talking about? When you find yourself having to add dependents, it's going to happen when you do that. Because I do get fight back from people. What you've explained is cool, but it's still more complex. I'm adding more to my application. It's like a lot of things in programming. You add a little up front for a lot of benefits down the line. When you set your stuff up good from the beginning, when you find yourself having to add dependencies at any level in your chain, let's say you have like a five level object graph. This class uses this one, this one uses this one, this one uses this one. All of a sudden, this one needs a little help from another class that you wrote. While as long as you register that class in the container, just add it to the constructor. Everything falls into place. You don't have to keep backtracking. What got me there? Because I got to knew it up somehow. No, the container will take care of all of that. And that's why I made the statement stop newing up classes. I think the only impact, usually the question I get is, is there an impact on performance? Any time you add a line of code to your application, there's an impact on performance, obviously. This uses reflection. So if you're one of those people that's a little reflection phobic, yeah, you're going to add nanoseconds of hit. Are you going to be able to tell the difference? Probably not. The most important thing is, are the benefits, is the return on your investment worth it? Like everything, you have to ask that question. You can't go into a programming project thinking it's always got to be about performance, because the performance of you as a developer is equally important. You know how clients are. They want it right now. Do you guys have the famous triangle that we have in the States? You can have it cheap. You can have it fast. You can have it good. Try it too. Try telling that to a client. It doesn't go over very well. You'll get a chuckle. That's about it. And then you're starving for the next six months. Besides, the reflection is, it's got to be used wisely, but if it's used wisely, reflection, the return on investment with using reflection properly is huge. Absolutely huge. I'm going to go through the first demo quickly, and then I have additional DI techniques that I want to show you, because that's why this session is called end-to-end. So let me see where we are. 606, all right, we're cool. Just to show you what this is set up like, this solution, I'm using this one project here for the rest of the hour, DI.autoFAC. But I have examples in Castle Windsor, Math, NINJEC, StructureMap, and Unity. And I'm going to show you all of them with just this first demo, this first example, so you can see what I'm doing. My demos are all, I take a lot of pride in the way I write my demos. I don't like to keep changing code on the fly, because then you take the code home, and you can't remember what was what and what changed to what. So all my demos are completely separate pieces of code, so you know exactly what they are, and they're numbered here. So this first one that we're going to do is called regular DI usage. And just to show you, if we have a worker class here, the order info, this is nothing but a data class. This is what's containing all the data that we're sending to the order. This will have a credit card number in here, whatever. And in AutoFAC, we have two classes that we deal with when we create a container. Usually containers have one class, the container. AutoFAC has the container builder, and then the container is generated from the builder. It doesn't make it that much different from any other container. It just makes it where it's two classes instead of one. That's all it is. And you're going to see the difference in a second with the other containers. So what I'm doing here is that I am creating a class called container builder, because it's off that builder class that I'm going to do my registrations. And this is how I'm registering here. Remember what I told you is just an association. This is in its simplest way possible. Association of a class to an interface. Now, you see one exception to that association of a class to an interface, and that's up here. I'll talk about that in a couple of minutes. But as you can see, I'm registering building processor to its interface, customer processor to its interface, and so on. Here's data repository to its interface. Then I'm building the container out of those registrations. That container is a static property on this program class, so the entire application has access to it. I'm resolving the commerce class. I'm not even newing up the commerce class. Remember, the commerce class has four argument dependency in its constructor. So if I'm going to new up the commerce class, I would have to say commerce OBJ equals new commerce, and then the constructor send in four different objects, and I don't want to do that. The whole beauty of using DI is that I can tell the container, please get me the commerce class. Now in a dependency injection container, they all have their technique for resolving. You can ask for either a concrete class or an interface. If you ask for a concrete class, you're going to get that concrete class with the entire dependency resolve process being done for you down the chain. If you ask for an interface, you're going to get whatever class that was associated to it registration. Some containers require you to register concrete classes as well. Some don't. Why? I have no idea. I think Unity requires you to register concrete class. I may be wrong. Castle and NINJECT do not. I guess we'll see in a second because I'll show you the code. But you can choose to resolve anything you want. If that anything happens to be a concrete class, auto fact specifically requires you to register it. I'm not associating it to anything, but I need to make auto fact aware of this class ahead of time. I really don't know why. Maybe it just likes to keep track of things. Once I do this, that whole resolve process starts. That whole reflection chain that I told you about, how it goes recursively down everything's constructor, every class is constructor until it's able to resolve everything and come back up, that's what happens with that simple resolve right there. So it's a very, very cool solution to obtaining a fully qualified instance of the commerce class completely filled with everything that needs to be filled. There was a time where I didn't have that data repository as a dependent. As a matter of fact, I didn't have it today. If I run this right now, I thought I just ran. Did I just run? No, I guess I didn't. I have five. Here we go. Did I mention that I embarrass people when they leave the room? Let's talk about him. Anybody know him? What country is he from? Come on, we got to insult him somehow. All right, check this out. Each one of those console right lines just ran. So all I did was call the process order. It resolved all the classes. Now I don't know if there's anything inside the repository, but let's find out. Watch this. If I go into that repository, what was that repository? Was it in customer processor? Yep, it was right here. It's down here. So let's say we do this right here. And here we're going to... I just ran everything successfully for you, but now I decided I'm going to refactor a lot of crap out of update customer order, put it into a separate class called customer repository or data repository because I want it reusable, make this whole situation testable by abstracting data repository to an interface, and then simply injecting that interface just like that. And now I can expand on the scope and actually make a call to save right here. That's all I need to do to have customer processor now depend on a data repository. I don't have to worry about newing it up. I don't have to worry about where's it being called from. It can be called from 15 different places. I don't care. Let's see if that works. They didn't even compile. Isn't that supposed to be your first unit test? Compilation? Whoa, what happened there? Oh, that was not my fault. That was code rush. Sorry, Mark. There we go. All right. Now let's see, one, order processing, payment process, log in. There you go, right there. We know we hit that class. Without worrying about having to new it up, where's it coming from, who has to new it up, where is this being sent into, it doesn't matter. As long as I register it, I can now use that in any constructor that I want. The container will take care of the resolve all the time. Pretty cool. That is about as simple as it gets. Yes, please. What do we do if Mark says that the system has one interface? So I'm going to answer that. The question was, I'm going to get to that. The question is, what happens if you have multiple classes implement one interface? How does that work out? The answer, I'm going to show you, there's two answers to that. One is, some containers allow you to register classes to the same interface and identify them with a string key. And then somehow you have to get that key at resolve time. I don't like that solution. I think it breaks, it brings me back to a little too much coupling. The most common scenario I have for multiple classes to the same interface is if I have some kind of plug-in situation where I want a collection of this interface to be injected into my class. That's the example I'm going to show you later. So I'm going to have three different classes that implement the same interface. I'm going to register all three to the interface. But then what my host class is going to receive in the constructor is not an argument of this interface type because the container will get confused if it sees that, even though you can mark one with the primary, being the primary. But I'm going to inject an I enumerable of that interface. And the container will actually instantiate all three of them and put them into that collection. And now my class has access to all the implementations of that. Those are the two primary scenarios that at least I can think of. Now there's other techniques that we deal with in the world of DI. And I get a lot of argument from people on this and I'll explain why. But I'll tell you what. This solution that I'm going to show you has saved my ass many, many times and it works. And I don't find anything particularly wrong with it, even though some people consider it an anti-pattern. I hate that term anti-pattern. I think that's a stupid term as the word code smell. To me, if you have a code smell, go take a shower and keep coding. So sometimes a class may receive many injections. Sometimes let's say the commerce class, for example, right now it's depending on four dependencies at the class level. Now that's because my process order method is using all four of those. But I can just as easily have a more complicated commerce class with let's say three different methods. One of the methods uses all four dependencies. One of the methods uses two dependencies. Another one uses just one of them. So depending on what my host application is doing when it calls commerce, it may call commerce with the intention of calling upon the method that uses one dependency only. So in that situation, I have unnecessarily forced a container to instantiate four different classes just to get the commerce class newed up. When at the end of the day, I'm only going to use one of them. So I have three classes that were instantiated unnecessarily. It doesn't sound like this is a big hit. And in the case of four, it's really not a big hit. But I have had classes where I'm depending on seven or eight or nine different dependencies. And I'm only using one or two. A very typical place, a thing for this scenario for me is I use a lot of WCF. I'm still very happy in the world of WCF. And I use dependency injection from WCF services. And some of my services have 10 or 12 operations. And a lot of them retrieve data. So I have a lot of different data repositories in my project. That service may actually depend on 10 or 12 data repositories. But the operation that I happen to decline happens to be calling. May only need two of them. So why do I need to instantiate the other 10 data repositories that I'm never going to use during that call? Object instantiation is not cheap. Make no mistake about that. It's heavier than reflection. Because there's a lot of stuff that has to happen with instantiation. I mean, you need to make sure that the heap has room for your object. The heap doesn't have room for your object. Then garbage collection needs to be run. The heap needs to be compacted. Generations have to be calculated. There's a whole ton of stuff that has to happen just to get that object out on the heap. And the pointer created on the stack. So if I can avoid instantiating 10 objects and instantiate just the two that I need, I'd prefer that. So this technique is for on-demand instances. It's basically called a service locator pattern. Another term for it is a data abstract factory pattern. Very, very similar. Those patterns are not identical, but they are pretty similar. And I'll show you how I do this. I'm just going to run straight to the code so I don't run out of time. Let me close this up. And I'm going to come out here and go to commerce2. Now take a look at commerce2. Commerce2 is not receiving as dependencies the iBuildingProcessor, iCustomer, iNotification, iLoggingProcessor. It's receiving this iProcessor locator class. And iProcessor locator class is an interface. So it does get registered in the container to a class. And the class that it gets registered to is this class right here. This is an auto-fac processor locator because it's using the auto-fac container right from there. So I'm just forcing, I'm implementing one method here called getProcessor of t and returning t. Now I can inject the iProcessor locator into my class and ask it to create the interfaces that I want because it's going to resolve them from the diContainer. Now in this particular method, I'm not gaining anything because I'm doing all four. But if I was calling another method that's only using one class, let's say the logging processor, and that's all that I need, then I'm instantiating the other three unnecessarily if I put them all up here. So this is a technique that I use pretty heavily. Has anybody ever watched any of my PolarCycorses? Nobody has one person. And three people. Thank you ladies. Thank you sir. I'm going to give you guys a big prize that nobody else gets, okay? Later on. It's probably a lot of money. Which course have you watched? So the building multi-client and service oriented application. That's the long one, right? The one that's like 55 hours long. Yeah. I know it's long. It's training. It's called training. I've watched my WCF course. So that's another number one course, and that one is, I think it's 11 hours long. But WCF's the topic that it takes me five days to teach it. I do a 40 hour onsite class on that. So these topics are big. Anyway, my point was not to digress to the course. In that course, I do this pattern. This should look familiar to you. Because this is what I'm doing with the business engine factory and the data repository factory. The exact same pattern. Exactly the same one. So the reason that a lot of people think to say that this is an anti-pattern is because they say that when you look at the, when your unit test looks at the constructor, all they see is this and you'll never have any knowledge of what dependencies your operations are going to use unless you look at the code for this dependency. You have to decide whether that's a problem for you or not. I don't have a problem looking at this and just seeing this. I'm going to go into the code and say, okay, this method is using these four. This method is using these two. I have no problem with that. It's for that only reason why this pattern, some people documented as an anti-pattern. The problem is that when somebody puts that into a book, other people read it and they think it's the Bible and all hell breaks loose. That's why I don't read books. Well, not tech books anyway. Anyway, so this is the service locator pattern and it solves the problem really, really well. Because now I can just ask for this one I want it. You can test this with no problem. I can create a mock for this and in that setup, I can do a mock of the processor locator and set it up so that when the get processor is called with iBuildingProcessor, return a mock of iBuildingProcessor. So I don't lose anything in unit testing. And I do all this for my plural site course. I show you how to write the unit test for it. It's doing it again, isn't it? It's not the podium. Huh? No, I don't think it's me. It's the guy back there. He's messing with me. He's got his hand on a little button. He's going, watch this. Ha ha. Mess with the American. All right, I got you. All right. To use this, it's no different. You just saw what the commerce class looked like. All I did was add the processor locator to the registration. That's it. I didn't change anything here except go resolve this. I didn't change that. I changed the commerce class. I changed the dependencies of the commerce class and what the implementation inside of it was, but everything outside of it, nothing has to be changed. I didn't change whatever. If something was calling the commerce class and it was not the container, that something would have to change because that something went from sending four arguments to sending one argument. But this has not changed at all. The container takes care of it all. So here's another one, instance lifetime. Instance lifetime is something that has been a problem. And I don't exactly agree with the way these containers were designed to handle this. But instance lifetime has to do with two things. One of them is the singleton versus transient, which is fine. That's easy. The other one is the disposable stuff, which I'll talk about in a second. Containers will let you register the associations, the classes, for conventional transient lifetime or singleton. What that means is that I can register any one of those things so that whenever anything down the chain asks for an instance of iBuildingProcessor, they get a new instance of iBuildingProcessor. I could also register it so that it's singleton pattern. So that when they ask for iBuildingProcessor, the container will see if iBuildingProcessor has been instantiated already. If it hasn't, it goes through the process of instantiating it, but now it holds onto it because it uses the same instance to feed any other requests for iBuildingProcessor. You get built-in singleton capability here. I'll show you that in a second. That's one scenario for instance lifetime. The other one's a little more hairy. The other one is when anything that you're going to resolve from a container implements the iDisposable pattern, the container is designed to hang onto that object even after your use of it has long gone. The explanation that I get about this is still a little weird for me because what I'm told is that it does that because the container does not know when you're going to call dispose on it, so it wants to hang onto it. But if I'm done using the object, I'm usually under the assumption that I have called dispose on it already, so I don't have to worry about that. So I don't want the container hanging onto it. And this can become a problem in a web application with memory leaks because now if you have, if you're using a good example, it's WCF proxies, which implement iDisposable. I tend to inject WCF proxies into MBC controllers or API controllers. And WCF proxies are already associated to the service contract. If you've ever done any WCF before, you've got a proxy associated to a service contract because that's what it implements. So it's already a perfect candidate for DI because I can register the proxy to the service contract as just a class to an interface. Then my MBC or web API controller can receive a constructor argument of type of the service contract interface and it'll take care of instantiating the proxy. But then after the request is done and that controller is gone because the web is stateless and it doesn't hang onto controllers, the container, which is stateful, is hanging onto that proxy because it implements iDisposable. Even if I already called dispose on it. So it doesn't make a whole lot of sense to me, but it becomes a problem because now you start loading up memory with instances that are not used anymore and that's what causes memory leaks. So this apparently is a known thing. I'm not going to say it's a known problem because the guys that write these containers will tell you it's not a problem at all. I consider it a small problem. I think it could have been handled differently, but there is a solution for it. And I'll show you what the solution for it is. And every container has got their own different way of doing it. Let me show you the singleton first. I'm going to run real quick the lifetime scope here. Oops. Uh... No, hold on. What did I do wrong? Did I screw something up when I messed up with this demo? What was that now? Oh, you're right. You're absolutely right. Thank you very much. That means I got to get rid of that. It was customer processor, right? Now what's another way that I can fix that? I'm going to comment this out, but how else can I fix it? Just register it. That's it. Register it and let the container take care of what it needs to take care of. Exactly right. By the way, about my and any other authors' Pluralsight courses, Pluralsight's got a booth out there. So if you guys need a free 30-day subscription, they'll be more than happy to hook you up with one. Uh... Keep in mind, all of the free 30-day subscriptions are only good for watching my courses. Okay, check out what just happened. Everything ran through, no problem. Counter inside a class. I have another class here called Singletester. The counter is set to one. I'm going to run it again. Oops. What's the counter set to? It's set to one. Why is that? Huh? No, it's not hard-coded, you smartass. All right. Which one is it? Commerce 3. There's Singletester, Display Counter. Singletester's down here. It just increments counter in the display counter and shows it. So it's class-wide variable being incremented at the method, but both times it was one. I've abstracted out so I can make it testable. As you can see, it's coming to use it. All I had to do was add it there. And we're a Singletester. There it is right there, and register it. But each time it ran, it was set to one. That's because every time that I ran it, the container is static in memory. It only gets registered once. But every time that I made a call to process order, as you can see, there's two calls right here. You just reinstantiate it, Singletester. If I wanted to change that behavior, I can do this. In AutoFac, all I have to do is add single instance. Every container has its feature. It's syntax, it's just going to vary. It's going to change a little bit. Say again? No. It holds it. Absolutely. As a matter of fact, I'll prove it to you. Singletester is set to one. It just incremented. It's a class-wide variable, so the same instance of the class has been reused. So the container is in charge of hanging onto it. Now the pattern for fixing the disposable problem differs from container to container. The way AutoFac does it is that AutoFac lets you temporarily create a kind of a subcontainer of itself. And then what it wants to do is it wants you to dispose that subcontainer because then that's when any instances of dependencies that that container has given you, if any of them are being held onto because they implement the IDisposable pattern, then the disposing of the container is what gets rid of those instances. But we obviously don't want to dispose our main container because we need that for the rest of our application. So AutoFac gives us this subcontainer kind of ability. And all I did was build that functionality into another version of the processor locator. So my original technique was not as cool, but at the same time I'm going to show you yet another cool feature of AutoFac. I know it sounds like I'm trying to sell AutoFac. I'm not. Use whatever you want. They all have these features. I'm just used to the syntax with this particular one. But this is the processor locator that you saw before. But what I'm doing is that when the processor locator is instantiating, I'm creating a scope. That creation of a scope is creating the subcontainer that I'm talking about in the scope variable. That scope variable is this lifetime scope. And it's off that scope variable that the get processor is going to resolve my dependencies. Because then when I'm finally done, from the hosting method, when I'm finally done using these dependencies, I need to make a manual call to release scope. And that subcontainer that I created gets disposed without touching the original container. My original technique for creating the subcontainer was by going to the static class and creating and doing a begin lifetime scope. But I changed it because I wanted to show you one other thing. There may be classes down the road that you write where you want to actually go to the container and resolve something. And you can do it this way, but there's a lot of people that have a problem with this. And I can understand that. Because what you're doing is that you're hard coding, you're coupling basically. You're hard coding something concrete into a class. Changing by saying go out to the container and get this, like in this case, I'm saying begin lifetime scope, but it can also say program container.resolve to get something. I'm still coupling to the container. AutoFact has a cool feature, and I think most of them have this, where automatically, AutoFact, the container itself has an abstraction that registers itself in itself, if you kind of get that meaning. I know it gets kind of weird, right? But the AutoFact container itself implements an interface called ILifetimeScope. And because that's automatically registered for you, AutoFact will resolve that for you. So I've injected, because this class gets injected into commerce, I've injected ILifetimeScope into here. So when AutoFact resolves processor locator 2 and it sees this, it's going to say, okay, what's ILifetimeScope registered to? Oh, it's registered to me, the container. So let me just take this container that exists, it's a Singleton container, and plug it into there so I can have access to it, and then this class can now do a bunch of resolves, does it do anything that it needs. Now I can't do a begin lifetime scope from, I mean, I can't do a resolve right from this, because this is not a subcontainer. I still need to create that subcontainer. This is the actual main container, the one that I created all the way the heck up here. It just happens to be made available to you by the container itself. Do you understand that weird twist of words that I'm using? But it makes it, it's a pretty powerful feature. When I learned about it, which is actually quite late, it was sometime in the middle of last year, I didn't know you can do this, I had in several classes, I had this kind of stuff here going on, and instead of scope, I would have this, right here, program.container.resolve. And I changed all of that so that anywhere where I had that, I was just injecting this, and now I can just do container.resolve. And the nice thing about it is that I'm programming to an abstraction, so now I can test this class if I wanted to, without being locked into a call to that static method, because it's going off an interface. So it's a cool feature that AutoFact has, and to the best of my knowledge, they all have that to some capacity. I know for a fact, who are the NINJEC users? So NINJEC, I think it's called kernel, am I correct? And NINJEC's got an ICernel interface, so I believe NINJEC, you can do that too. You can inject the ICernel interface, and it's the same thing as injecting this. You're injecting the container itself, so you can do resolves from it. Did you give a hand up? Nope? Any questions? Already did this? Already did that? Okay, there's other ways of doing registration, and I'm going to show you a couple of them. We've got like five minutes left. Is this the last? It is the last. They put me, you know I got off a plane this morning, and got into the tube, got to the hotel, slept for one hour. So if I mess things up, I may be giving you complete horseshit, okay? It's just from lack of sleep. All right, let me show you other ways that you can do registration. I got a couple of demos on it. I really wish that I had a full 75 minutes. So this is assembly scanning. If you set your classes up with nice naming conventions, which is always a good idea, you decide what the naming conventions are. You don't have to copy mine. Just if you work with a team or you head up a team, naming conventions should be a my way or the highway thing. Which is don't let your developers run rampant on their own conventions. Establish a set of conventions and ensure that they're followed. And in my particular case, I have 100 dependency classes in this project, pretend. But four of them are these processor classes. I set up a naming convention for my processor classes. The naming convention is that there's something, something, something, processor. Very simple, just for demo purposes, right? So what I did here is that instead of registering all the processor classes one at a time like this, what I did here, I registered commerce because I had to. And then I said register assembly types from the following assembly. In this case, it's the executing assembly. But you figure out how you need to get that assembly. It can be off a type, like a type of something.assembly, any type in the assembly will do. And I'm going to say of all the types in that assembly, I can use a lambda expression here. Grab me the ones where the name ends with processor. And then I'm going to register them as an interface. Each one of them is going to be an interface. What's the interface going to be? Well, I'm going to lambda expression in and I'm going to grab for each of the types, whatever type I happen to be in, get the interfaces for it and grab the interface that starts with the letter I and ends in the name of the type. Just following a naming convention. So billing processor has I billing processor. Customer data repository has I data repository. In this case, it's just processor. But you understand what I'm talking about when I say conventions. By doing that, I can now add more processor classes and I never have to go in and register them because I have this one technique that registers them. That's one example. And the demo is exactly the same as the other one. It just shows you that it works. This is another thing that all the containers have. I only know how to use it in AutoFact, but I know that they all support modules. As you can see here, I'm registering a type, but now I'm registering a module and that's it. Why is that? Because I can now break out my registration in different classes. This is that inherit from auto fact dot module, override the load and in there you get the builder and now you just do your registration. Whether it's this or hard code registration, whatever you want. But now you can break them up. And I have a module that's my business repositories. I have a module that's my data repositories. I have a module that's my WCF client proxies. Just a nice way of breaking out your registrations. And also these modules can now come from different assemblies. WCF fact also has the ability that there's a new package called auto fact configuration. And what it is is that it's a built in module whose job it is to go out to the config and read config information and grab the type and interface from there. So yet another way of registering it. I see that red light. Can I have two more minutes guys? Well I know one person in particular wants to see this one. So this is one to many. Who was it that asked that question? Who's you, right? So here's building processor, customer notification, login processor. And then here's an assembly type registration where I'm saying go to this assembly and register anything that starts with the word plug-in, register it to ipostorder plug-in. And I have three classes. I post order plug-in. I think they're just called plug-in one, two, and three if I'm not mistaken. Here we go. Plug-in one, two, and three. How complicated is that? Each one is simply just going to say plug-in number one executed number two and number three. So by registering multiple classes to one interface, I've just confused the situation because now it's going to be up to my commerce class to do things the right way. Because if commerce receives an injection of ipostorder plug-in, just one of them, it's going to get auto-faxing to get confused. And every container handles this separately. I think one of the containers, I don't remember which one it is, will actually default to the first of what is maybe many registrations to that same interface, it'll just take the first one. If you ask for one, it'll give you the one at the top of the stack. Auto-fax does not do that. Auto-fax will actually tell you, you must tell me which one of these you want. And there's like a string identifier for it. I can't remember how to use it. All of them support this, which to me is the more common scenario, which is you inject an I enumerable of that. Because now you have all of the plug-ins, and now you can do with them whatever you want. And all I'm doing is iterating through the collection and calling in do something. So it's a great technique for doing plug-in and modular architecture. Does that answer your original question? I'm going to skip that because it's rarely used. I want to get to that one there. Deterministic constructor injection. This one's very cool. And I cannot tell you, even if the other containers have this capability, I know that Auto-fax does and it's helped me, and I know that Meph does because Meph actually forces it on you. And what I'm talking about is the following. I got a class with more than one constructor. I'm surprised nobody's asked this question. What happens if a class has more than one constructor? Which one is it going to use? Every container does things differently. Auto-fax and Unity, and I think probably most of them, if not all of them, will actually take the constructor with the most arguments and use that constructor. But that may not always be the case, in my case here. As you can see, this constructor has more arguments than this one. Yet this one is used by, I don't know what the hell this is used by, somebody else is using this constructor and sending in four integers in there. But this one is depending on dependency injection. However, the Auto-fax is going to, by default... I should have had this commented out. Sorry. So as you can see, you can do so much more with these containers, more than what we have time for. But you could actually come up with default arguments in case it encounters this A argument, put the number one in there, that kind of thing. But watch this. Eight. Watch where it breaks. It breaks here. Now Auto-fax is automatically going to use this because it's got four constructor arguments instead of three. So it's the one with the most. And it's going to send in the number one, because that's what I just told the container, when it encounters A send in a one, B send in a one, and so on. But then my call is going to go to process order, and it's going to come and run this code. And that's going to happen when it gets there. It's immediately going to break. Why is it going to break? Because processor locator is null. Because that came in through the other constructor. So the point of this last exercise is how do we get deterministic constructor injection? Something that if you've used mef, who's used mef before? MEF. So you know mef has got the importing constructor argument. So in mef, you're forced to tag the constructor that you want to use, you have to tag it with that. And for people that think that's dirtying up your code, it actually helps you quite a bit because it automatically solves this problem. Because you told mef, I have 15 constructors on. It got help you if you really got 15 constructors. But I got a boatload of constructors. This is the one that I want the container to use. Well I want to mimic that scenario here. So I want to do it by using my own very appropriately called awesome constructor attribute. So what is this awesome constructor attribute? Does the awesome constructor attribute solve the problem for me? It doesn't do anything. A constructor is only as good as that which looks for it. The constructor itself is not doing a damn thing. But something has to be looking for awesome constructor attribute. So what is looking for it? Model fact has this concept of a constructor finder. So I wrote awesome constructor finder and I have to implement the find constructors. This is the type that is about to be resolved. In my case commerce. I do whatever I need to do to determine what constructor to use. In my case, I'm looking for the constructor that's got that attribute. If you want to use the first constructor, go ahead. If you want to say if it's a full moon and it's on Tuesday, use the third constructor just to mess with somebody, you can do that too. I say use the one that's got that attribute on it. So now that I got this constructor finder, I can install it like this. Do my registration but then add here find constructors with an instantiation of new constructor finder. And that's it. That solves the whole problem because now when I run this, the constructor that it breaks in is that one. And my code continues to run and everything is fine. And there's my plug-ins, by the way. So guys and gals, this is all we have time for. This is actually the last demo without going into the projects. But the projects are here for you to mess around with. I'm at your disposal. Feel free to email me, Twitter me, whatever if you need help with this. It's this whole usage scenarios auto fact section at the end here. You got an MBC application, WCF web forms and WPF all using auto fact and showing you how to use dependency injection. In WPF, I show you how to do it with view models, in MBC, I show you how to do it with controllers. So it's some pretty cool demos. I wish we had time for them. But the code is all yours. I give the code to the people here. I don't know if they have a site for it or not. But I have a place where they will be up on and I can probably do it as early as tomorrow. I don't have to wait until I get home. But go to my website, my company website. There's a downloads link on there and you'll see a list of conferences. NDC will be the most recent one. And you'll just see the two sessions that I'm doing here on there. And you got the slides, the code, everything. The demos are laid out pretty good. So I think you can get a lot from them. I'm speaking again on Friday morning and then I'm flying out Friday afternoon. I'm doing a talk on how to play nice with ASP.net, MBC, and Angular. Any Angular junkies here? That's it. What are the rest of you use? Nothing? Anyway, come see me again. I hope you enjoyed this. Please give me an eval. Hopefully there's no red ones left. Actually, I shouldn't have said that. That means that they've been used. But give me an honest eval. And we use this information quite religiously. So please don't forget. And that's it. Enjoy your day. Have a great rest.
 I don't do Q&A at the end of a talk.  If you have a question, just raise your hand and ask me in the middle of it.  I don't want you to lose your train of thought in asking a question, so I don't make you  wait till the end.  I'll be repeating the question so we can have it on the record since this whole thing is  being filmed and recorded.  And welcome to DI.  So I want to ask a question because I'm going to anticipate what you guys may not ask, but  I usually get this asked by a lot of other speakers.  People will approach me and say, why are you still talking about DI?  Everybody's doing that.  And I don't know about Europe because it's a very, very different audience, but how many  people here use dependency injection mainstream in all their applications at work in the  projects they're working on?  You see?  A handful of you, probably less than a quarter of you.  In America, an audience of this size, I get two or three people that raise their hands.  And it's really a sad thing because that's the whole reason why I still talk about this  subject.  This is one of those things that needs to become mainstream.  It's a very important part of software development today, and it's not rocket science.  It's not difficult to do, and the benefits are huge.  There was a time several years ago where dependency injection and version control, containers,  all those kind of, that kind of lingo was what the cool kids were doing, right?  It was the buzzwords.  And everybody wanted to do it because it just sounded really cool, and I know that's what  the experts are working with.  It's not like that anymore, and it shouldn't be like that.  It shouldn't have been like that back then.  This is something that's important, and that should be part of all of our software development.  What's going on with that thing?  Am I supposed to avoid that section?  I don't know.  All right.  So, what we're going to talk about is the difference between coupling and non-coupling.  Now, some of the stuff that I am going to go over, you may already be familiar with,  but I do things in a step-by-step process because I'm going to build up to the actual  usage of DI.  This talk is supposed to be a 75-minute talk, but in NDC, they only do 60 minutes.  So, you're going to find me rushing through a couple of things.  I'm going to try not to rush.  What I'm going to do instead is there's a section at the end here.  What is going on with this thing?  What was that?  Did you say post back?  This freaking thing was written in web forms.  Is that what you're saying?  So, I go through the explanation of the dependencies and what coupling is and how with coupling,  you don't have testing.  I'm going to go through that and get into decoupling and why testable software is very  important and what is the basis for testable software.  Then I'm going to get into dependency injection because the truth of the matter is that in  order to use dependency injection, you have to set the groundwork for it.  The groundwork comes in making your software testable.  If you can get to that point and abstract enough to make your software testable, you've  accomplished more than your average developer, at least in the states, which is a sad statement  for me to make, but that's the God-honest truth.  Then from there on, DI can help you take it to the next level.  Now, I'm going to go through all of this because I use AutoFac, by the way, in my examples,  but I do have code samples for you to take with you that are in all the other containers,  probably four or five other containers, including MEPH.  But AutoFac is my container of choice.  The area here is what I may or may not get to, depending on how we do with time.  What this is, they're four complete working examples of dependency injection usage in  all these four types of applications, including a webforms applications for this post-bac  guy right here.  You got some real good real-world usage scenarios there that I will try to get to, but I'm not  going to guarantee it because of the fact that I only have one hour.  All of this starts, this thing is flickering, by the way.  Every once in a while, it just kind of flickers.  Let's see if it's not going to do it.  It's like bringing your car to the mechanic.  It doesn't reproduce the noise, so it's not going to reproduce it now.  The idea of writing testable software involves breaking this lifelong habit.  The lifelong habit involves class coupling.  I'm going to get into that.  I'm going to go back to that statement in just a second.  Coupling very simply, as I'm sure a lot of you know, is just one class depending on another.  The class cannot exist, cannot function, most of the time it can't compile without some  kind of partnership class, some kind of partner class.  This has a lot of limitations.  The first one is that it limits you to single implementations because you got one concrete  class depending on another.  For example, you got one class that performs database work in your data access layer.  You got a business engine class that calls upon that.  Those things are very tightly coupled.  If they're very tightly coupled, it becomes difficult to test.  The reason it becomes difficult to test is because you can't write a unit test against  that business engine class without it hitting your database, which is not something that  you want to do in a conventional unit test.  That's something that you reserve for what we call integration tests.  This kind of coupling where we have concrete classes depending on one another is generally  bad.  Now, why is it bad?  Well, the answer to that question is in the secret to writing testable software, which  is that breaking a lifelong habit that I told you about, and that is stop newing up objects  inside a class.  Now, my general experience with European audiences is that they're a little more advanced than  a lot of audiences that I speak to in the States.  I don't know what the reason for that is.  I don't think it's because your skill level is higher than American programmers.  I think it's because American conferences attract primarily newbies.  At least that's been my experience.  When I make a statement like this in front of 100 people that are just got into programming  two or three years ago, it's usually a shock and awe statement.  What do you mean stop newing objects in class?  How else do you expect me to instantiate an object?  Well, there are other ways of doing it.  The first step to writing testable software is to embrace abstractions, and you do that  by using interfaces quite a bit.  This gets, I get fight back on this statement quite a lot because people tell me, well,  that's why I don't like to code that way because I end up with almost an interface for every  class.  Yeah, you kind of do.  That's not a bad thing.  There's nothing wrong.  We're programmers.  We like to program.  We like to write code.  Why are we trying to get out of the idea of writing code if it's the right code to write?  Having an interface for most, if not all of your classes, lets you pass these interfaces  around.  This limits the coupling massively because now one class does not depend on a concrete  instance of another one.  It depends on an abstraction, a definition of it.  Now that definition can vary depending on the scenario.  The production world, the definition of a class that gets used by another is one implementation  in a testable scenario, in a test world, it may be a different implementation.  Let's go back to that example about the data access layer class.  You have a concrete implementation to production that uses entity framework and system data,  ADO.net, all that fun stuff to actually access SQL server.  But in the testing scenario, you can use a test version of an interface, so it's a different  class.  It's got the same create, read, update, delete, same methods that normally go to the database,  but they do something else that don't physically hit a database.  Now by passing that implementation into another class, you've just made that class extremely  testable.  This is going to make a lot more sense when I show you code.  Actually, I'm going to show you code right now.  How about that?  I guess you guys rather stay in PowerPoint.  What do you prefer?  All right.  Where is – so this is a very simple coupled example.  I'm just going to go through it really – it's stupidly simple because all I have here is  I have a commerce class that's got a method called process order.  The commerce class has broken out the idea of processing a customer's order into four  different steps.  One of them is to update the customer database.  The other one is to run the customer's credit card.  Another step is to log the information to like an audit log or something.  The other one is a notifier step which sends out an email to the customer saying, thanks  for your order, here's your receipt.  I got these steps broken out into four different classes.  All the steps you're doing is writing out to the console, so obviously you're not doing  anything crucial.  This is where you would process a customer's credit card.  This is where you would write out product and customer purchase information to an actual  database.  This is where you would use, let's say, log for net or something to write out to an audit  log that may go to either a text file or a database.  This one is going to access system.mail to actually send out an email.  All of these have pretty concrete implementations of what they're supposed to do and the kind  of implementations that you don't want to run over and over again if you were testing  this class.  If we're running all four of those steps from this commerce class here, the commerce class  is going to rely on those four helper classes.  As you can see, they're completely tightly and very poorly coupled to the commerce class  because they're being instantiated right here.  If I'm going to instantiate this class in a unit test scenario, I'm going to have the  exact same effect as if I'm running it in production.  That's not what I want.  I want to access the database from here.  I don't want to send out an email every time that a unit test is run.  This is a perfect example of just some really poor coupling.  How does this get fixed?  Very, very easy, actually.  If all of these classes have a corresponding interface that defines them, in this case,  iBuildingProcessor defines this one, as you can see, it's just a quick definition.  The other four, which I won't bother showing you, are exactly the same.  They just have a corresponding interface.  Now that's what's being used here.  Now as you can see, I can instantiate the commerce class and send in instances of these  classes during production.  The beauty of this technique now and why it's considered testable is because now from a  unit test, I can decide what I want to send into here that does not actually perform those  concrete steps.  It does not send out a physical email or notify the client, does not update the database,  and certainly does not process a credit card.  Can you imagine that concrete step being run over and over again in a unit test?  That's not what we want.  In a testing scenario, we would like to set up test versions or test implementations of  each of these interfaces.  That becomes a whole lot of work.  That's usually one of the reasons why I get pushed back from people.  Well, if I have an interface, now I've got to have a production implementation, I've  got to have test implementation.  First of all, yes you do.  That's just good coding.  It's good programming to have two different implementations, one for production, one for  test.  It's an easy way to get the test done that I'm sure at least some of you in this room  have done something with.  Has anybody worked with the mocking framework before?  All right, quite.  You see, more people than have worked with the DI container.  How about that?  That's weird, to be honest with you.  So this is an example of using a mocking framework.  I don't know what Visual Studio does, those retarded things once in a while.  It just stops.  You ever get the general message from Visual Studio saying I'm busy?  Visual Studio is busy.  Is that rude or what?  I got shit to do.  Don't tell me you're busy.  All right, so this is an example of using Mach Q.  Now, I'm not going to go through a tutorial on Mach Q, but just to show you what I've  done here is that ultimately I need to instantiate my commerce.  But obviously my commerce class needs four instances of each one of those objects, those  implementations of those four interfaces.  What a mocking framework allows you to do for those of you that have never seen it before  is create a test version of an interface, a test implementation of an interface, but  do it all at runtime.  And depending on how the mocking framework is written, the language is just going to  vary a little.  Here, all I'm doing is that I'm creating an object that's a mock of iCustomer.  Then I am taking mockCustomer and setting it up.  And what you can do in the setup here is a ton of different things.  I'm keeping it very simple.  I'm saying whenever you call updateCustomerOrder with any string and with any string, don't  do anything else.  But if customer order happened to return something, I can then do a returns here and return whatever  the object is that it needs to return.  If I wanted to set up this mockCustomer so the updateCustomer works only if this string  is something specific and this string is something specific, I can set it up that way.  Once I have my whole mock set up, I can just address it as mockCustomer.object.  And this type right here is actually an implementation of iCustomer.  So the mocking framework should definitely be in your toolbox as you start writing testable  software, as you start writing software that is geared for testability.  Very important.  And now I can run this unit test.  And remember the idea of the unit test is to test that process order, complete it without  exception.  It's not the test that process order updated the database, send out an email and process  a credit card.  That's an integration test.  I just want to make sure that that unit complete it without exception.  And I can do that by sending these mocks into there.  So very, very simple process.  Now if I go out to here, you notice that this class cannot work, cannot instantiate without  four implementations of these dependencies, these dependent classes.  So something has to instantiate these classes and send them in.  Obviously whatever the caller is.  Now this is where the use of a product helps us a lot.  And that's product is known as a dependency injection container.  I'm not here to push any product.  I happen to like AutoFact because it's what I use and it's easy for me to use.  But use whichever one you're familiar with.  Anybody use Castle Windsor here?  Okay, three people.  Structure map?  Two, three.  Ninja.  Couple more.  Unity.  I'm sorry.  What about AutoFact?  Okay.  They're all good.  The language for them is just a little different, that's all.  AutoFact happens to be the, I think it's the newer one.  So it was written in.NET 4 or 3.5 or 4, so it's one of the newer.  But they all do, you know, these guys that wrote these containers are very competitive  with each other.  So, you know, if one guy adds something to Castle Windsor, then Jeremy who wrote structure  map immediately goes and puts out an update for structure map to compete with what Castle  Windsor just received.  So they're all going to do very, very similar things.  It's a dependency injection container that is going to not only take care of injecting  these dependencies into this class, but is also going to eliminate that rule that I told  you earlier that I said was usually a shock on our rule of not newing objects up.  Because something has to new it up, right?  If this class is not going to new up these classes, which we don't want it to, then whatever  calls commerce is going to be newing up these classes and sending them in.  But we're going to eliminate that as well.  And we're going to do it in a very cool way, because I'm going to show you how recursively  we can go as low as we need with one class calling another, calling another, calling another,  and let the dependency injection container take care of everything for us.  Let's go back to the slides real quick.  So dependency injection in general is just a pattern.  It's an architectural pattern that's designed to satisfy the dependencies in a class.  You just saw an example of one class with four dependencies.  It helps us resolve the dependencies when we wrote our code in a very decoupled way.  So we're going to do that without having to worry about instantiating those dependencies  from any level in our object chain.  We eliminated the instantiation from that commerce object, but like I said, something  has to instantiate it.  Well, we're going to actually eliminate that as well.  You're going to see how cool it's actually going to be.  So this pattern gets a lot of help with the help of this product, this product known as  a container.  Another term for dependency injection containers and inversion of control container, the terms  are kind of used interchangeably.  Put simply in its basic form, a DI container, as I'll call it going forward, is all about  two things, registration and resolve.  A DI container will have a registration phase at the beginning of an application done once  only.  If it's a web app, it's done in the global ASAX or a class that's called by global ASAX.  If it's a WPF or WinForms or some kind of desktop app, it's done at the beginning of  app load probably while the splash screen is loading, but it only needs to be done once.  And the container itself is held on to class wide, statically, typically.  And all registration is the association, the building of a list of key value pairs  associating a class to an interface.  In its simplest form, I say simplest form because there's a couple of things that I'm  going to throw in there that are going to complicate it a little more, but that's good.  I suspect you guys are not newbies, so a little complication in your life, especially when  it comes from an American, is a good thing, right?  That was supposed to be funny.  Laugh a little.  We're on the record.  It's being recorded.  Laugh into the microphone.  All right, so it's about building a bucket of key value pairs.  I hesitate to use the word bucket list because it's very morbid, but it's a bucket of key  value pairs associating one class to an interface.  This is what's called, this is registration.  So in the examples that I showed you, the building processor class is associated with  the iBuildingProcess interface, the logger class with the iLogger interface, and so on.  And some of these registrations can get really, really long.  I've been known to register 200, 300 different classes for a large project.  Every container has multiple ways of doing its registration.  Most of them now support all of these things.  The most common way of doing it is procedural, which means you're going to see an actual  code statement that registers, register this class to this interface.  But there's ways of storing those associations in a config file.  There's ways of doing discovery.  Mef does it through discovery, where you tag classes with an attribute, and that attribute  relates it to the interface.  So later, Mef goes out and discovers everything in your types with who's using this attribute,  and this is how I can tell that this is the interface that you're using.  So there's multiple ways of doing it.  We're going to stick with the procedural way in our examples.  The second thing that the container is used for is the resolve process, and that is when  the need for a dependency is encountered.  And I'll go over the detail on when that is.  But when that need is encountered, the container will say, OK, I have a property or an argument  or something here that's a type iBuildingProcessor.  Let me go into that bucket list that you created during registration and figure out what is  iBuildingProcessor associated to.  Ah, it's the building processor class.  Let me new it up and inject it into that constructor.  And that's how the container is going to take care of us not having to new up objects  anymore.  But this is where it gets really, really cool, because it kicks off a chain reaction, a DI  resolve chain reaction.  So let's go back to that example again.  You saw the commerce class relying on four constructor arguments of four interface types.  When that commerce class is created, and it's going to be created by the container, the  container is going to resolve it.  The container is going to use reflection, and there's reflection involved here, so get  over it.  If you have a fear of reflection, get over it.  Reflection is not as heavy as people think if you used right.  The container is going to take that commerce class.  It's going to reflect into it.  Look at the constructor and see that it's expecting four interface types.  Now before the container can new up the commerce class, it knows that it needs to instantiate  those four classes so that they can inject them in there.  So it's going to go to each one.  So it starts with the building processor.  It goes back into its bucket list and says, OK, I building processor is associated with  the building processor.  So before it news up building processor, guess what it does?  It goes into the building processor class, looks to see if it's got any dependencies  in its constructor.  If it does, it performs the exact same process.  When it finally gets to a bottom of the chain where it has no more recursion, no more dependencies  to resolve, it then says, OK, now I'm ready to new this class up.  Take the instance of that and inject it into this one.  Finish the dependencies for this one.  Once this is done, new this one up, inject it into this one.  Finish the dependencies here.  And it keeps doing that back up the chain until it gets to the original host that asks for  the commerce class.  What this means is that this class right here has only four dependencies.  However, this class has no dependencies, but I commented out some code here that I did  for the previous session that I did at the previous conference where this building processor  had a dependency for a data repository to access the database.  If that interface, iDataRepository, is registered to an actual data repository class with my  container, then when the container goes to resolve this here, when it sees this, it hasn't  instantiated this yet.  It's still in the reflection phase.  When it sees this, it says, OK, let me go into this one and new it up.  Oh, hey, I can't new this up yet.  It's got a dependency.  So let me go into here.  What is this registered to?  A data repository class.  Does this have any constructors?  Nope.  This one doesn't.  No dependencies.  So let me new up the data repository, put it into there.  Now there's no more dependencies.  I can now new up building processor.  Now I have a class that I can inject right into there.  This is the container talking.  I can inject it into there onto the next one, and it performs the same process for the next  one.  The beauty of this is that once you have all of your classes in your project registered  with a container, you can start using class.  I made the decision to add the dependency of idata repository to building processor later  in my project.  Perhaps I had data access stuff in here, hard coded into here, for whatever bad reason,  because I was a poor programmer.  I just had pure ADO.NET in here.  I didn't like it.  I refactored it into a data repository class.  And then what do I have to do to add that to building processor?  All I got to do is add it as a constructor there.  The container will take care of instantiating it for me.  It's a very, very nice solution.  If I didn't have the container, but I went ahead and I did all of this decoupling, I've  gone halfway.  I've gone a very good way, because I've written testable software.  By getting just to the point of embracing these abstractions and working with these interfaces,  you're writing testable software.  You're doing things much, much better.  But you're also doing things a little harder.  You're making it harder for yourself, because now, yes, I'm able to test these classes because  of the abstractions.  But now, whatever is instantiating building processor has to inject that in there manually.  And if that something is up here, well, I don't want to knew it up in here.  So now, whatever is installing this has to inject, has to knew up building processor,  and in turn, has to knew up data repository, and have knew of this, knew of this, knew  of that, and then knew up commerce with the string of constructors.  And it just becomes a lot more difficult.  You're going to see how easy it is when I show you the DI code.  Everybody got a pretty good idea of what I'm talking about?  When you find yourself having to add dependents, it's going to happen when you do that.  Because I do get fight back from people.  What you've explained is cool, but it's still more complex.  I'm adding more to my application.  It's like a lot of things in programming.  You add a little up front for a lot of benefits down the line.  When you set your stuff up good from the beginning, when you find yourself having to add dependencies  at any level in your chain, let's say you have like a five level object graph.  This class uses this one, this one uses this one, this one uses this one.  All of a sudden, this one needs a little help from another class that you wrote.  While as long as you register that class in the container, just add it to the constructor.  Everything falls into place.  You don't have to keep backtracking.  What got me there?  Because I got to knew it up somehow.  No, the container will take care of all of that.  And that's why I made the statement stop newing up classes.  I think the only impact, usually the question I get is, is there an impact on performance?  Any time you add a line of code to your application, there's an impact on performance, obviously.  This uses reflection.  So if you're one of those people that's a little reflection phobic, yeah, you're going  to add nanoseconds of hit.  Are you going to be able to tell the difference?  Probably not.  The most important thing is, are the benefits, is the return on your investment worth it?  Like everything, you have to ask that question.  You can't go into a programming project thinking it's always got to be about performance, because  the performance of you as a developer is equally important.  You know how clients are.  They want it right now.  Do you guys have the famous triangle that we have in the States?  You can have it cheap.  You can have it fast.  You can have it good.  Try it too.  Try telling that to a client.  It doesn't go over very well.  You'll get a chuckle.  That's about it.  And then you're starving for the next six months.  Besides, the reflection is, it's got to be used wisely, but if it's used wisely, reflection,  the return on investment with using reflection properly is huge.  Absolutely huge.  I'm going to go through the first demo quickly, and then I have additional DI techniques that  I want to show you, because that's why this session is called end-to-end.  So let me see where we are.  606, all right, we're cool.  Just to show you what this is set up like, this solution, I'm using this one project  here for the rest of the hour, DI.autoFAC.  But I have examples in Castle Windsor, Math, NINJEC, StructureMap, and Unity.  And I'm going to show you all of them with just this first demo, this first example,  so you can see what I'm doing.  My demos are all, I take a lot of pride in the way I write my demos.  I don't like to keep changing code on the fly, because then you take the code home,  and you can't remember what was what and what changed to what.  So all my demos are completely separate pieces of code, so you know exactly what they are,  and they're numbered here.  So this first one that we're going to do is called regular DI usage.  And just to show you, if we have a worker class here, the order info, this is nothing  but a data class.  This is what's containing all the data that we're sending to the order.  This will have a credit card number in here, whatever.  And in AutoFAC, we have two classes that we deal with when we create a container.  Usually containers have one class, the container.  AutoFAC has the container builder, and then the container is generated from the builder.  It doesn't make it that much different from any other container.  It just makes it where it's two classes instead of one.  That's all it is.  And you're going to see the difference in a second with the other containers.  So what I'm doing here is that I am creating a class called container builder, because  it's off that builder class that I'm going to do my registrations.  And this is how I'm registering here.  Remember what I told you is just an association.  This is in its simplest way possible.  Association of a class to an interface.  Now, you see one exception to that association of a class to an interface, and that's up  here.  I'll talk about that in a couple of minutes.  But as you can see, I'm registering building processor to its interface, customer processor  to its interface, and so on.  Here's data repository to its interface.  Then I'm building the container out of those registrations.  That container is a static property on this program class, so the entire application has  access to it.  I'm resolving the commerce class.  I'm not even newing up the commerce class.  Remember, the commerce class has four argument dependency in its constructor.  So if I'm going to new up the commerce class, I would have to say commerce OBJ equals new  commerce, and then the constructor send in four different objects, and I don't want to  do that.  The whole beauty of using DI is that I can tell the container, please get me the commerce  class.  Now in a dependency injection container, they all have their technique for resolving.  You can ask for either a concrete class or an interface.  If you ask for a concrete class, you're going to get that concrete class with the entire  dependency resolve process being done for you down the chain.  If you ask for an interface, you're going to get whatever class that was associated  to it registration.  Some containers require you to register concrete classes as well.  Some don't.  Why?  I have no idea.  I think Unity requires you to register concrete class.  I may be wrong.  Castle and NINJECT do not.  I guess we'll see in a second because I'll show you the code.  But you can choose to resolve anything you want.  If that anything happens to be a concrete class, auto fact specifically requires you  to register it.  I'm not associating it to anything, but I need to make auto fact aware of this class  ahead of time.  I really don't know why.  Maybe it just likes to keep track of things.  Once I do this, that whole resolve process starts.  That whole reflection chain that I told you about, how it goes recursively down everything's  constructor, every class is constructor until it's able to resolve everything and come back  up, that's what happens with that simple resolve right there.  So it's a very, very cool solution to obtaining a fully qualified instance of the commerce  class completely filled with everything that needs to be filled.  There was a time where I didn't have that data repository as a dependent.  As a matter of fact, I didn't have it today.  If I run this right now, I thought I just ran.  Did I just run?  No, I guess I didn't.  I have five.  Here we go.  Did I mention that I embarrass people when they leave the room?  Let's talk about him.  Anybody know him?  What country is he from?  Come on, we got to insult him somehow.  All right, check this out.  Each one of those console right lines just ran.  So all I did was call the process order.  It resolved all the classes.  Now I don't know if there's anything inside the repository, but let's find out.  Watch this.  If I go into that repository, what was that repository?  Was it in customer processor?  Yep, it was right here.  It's down here.  So let's say we do this right here.  And here we're going to...  I just ran everything successfully for you, but now I decided I'm going to refactor a  lot of crap out of update customer order, put it into a separate class called customer  repository or data repository because I want it reusable, make this whole situation testable  by abstracting data repository to an interface, and then simply injecting that interface  just like that.  And now I can expand on the scope and actually make a call to save right here.  That's all I need to do to have customer processor now depend on a data repository.  I don't have to worry about newing it up.  I don't have to worry about where's it being called from.  It can be called from 15 different places.  I don't care.  Let's see if that works.  They didn't even compile.  Isn't that supposed to be your first unit test?  Compilation?  Whoa, what happened there?  Oh, that was not my fault.  That was code rush.  Sorry, Mark.  There we go.  All right.  Now let's see, one, order processing, payment process, log in.  There you go, right there.  We know we hit that class.  Without worrying about having to new it up, where's it coming from, who has to new it  up, where is this being sent into, it doesn't matter.  As long as I register it, I can now use that in any constructor that I want.  The container will take care of the resolve all the time.  Pretty cool.  That is about as simple as it gets.  Yes, please.  What do we do if Mark says that the system has one interface?  So I'm going to answer that.  The question was, I'm going to get to that.  The question is, what happens if you have multiple classes implement one interface?  How does that work out?  The answer, I'm going to show you, there's two answers to that.  One is, some containers allow you to register classes to the same interface and identify  them with a string key.  And then somehow you have to get that key at resolve time.  I don't like that solution.  I think it breaks, it brings me back to a little too much coupling.  The most common scenario I have for multiple classes to the same interface is if I have  some kind of plug-in situation where I want a collection of this interface to be injected  into my class.  That's the example I'm going to show you later.  So I'm going to have three different classes that implement the same interface.  I'm going to register all three to the interface.  But then what my host class is going to receive in the constructor is not an argument of this  interface type because the container will get confused if it sees that, even though you  can mark one with the primary, being the primary.  But I'm going to inject an I enumerable of that interface.  And the container will actually instantiate all three of them and put them into that collection.  And now my class has access to all the implementations of that.  Those are the two primary scenarios that at least I can think of.  Now there's other techniques that we deal with in the world of DI.  And I get a lot of argument from people on this and I'll explain why.  But I'll tell you what.  This solution that I'm going to show you has saved my ass many, many times and it works.  And I don't find anything particularly wrong with it, even though some people consider  it an anti-pattern.  I hate that term anti-pattern.  I think that's a stupid term as the word code smell.  To me, if you have a code smell, go take a shower and keep coding.  So sometimes a class may receive many injections.  Sometimes let's say the commerce class, for example, right now it's depending on four  dependencies at the class level.  Now that's because my process order method is using all four of those.  But I can just as easily have a more complicated commerce class with let's say three different  methods.  One of the methods uses all four dependencies.  One of the methods uses two dependencies.  Another one uses just one of them.  So depending on what my host application is doing when it calls commerce, it may call  commerce with the intention of calling upon the method that uses one dependency only.  So in that situation, I have unnecessarily forced a container to instantiate four different  classes just to get the commerce class newed up.  When at the end of the day, I'm only going to use one of them.  So I have three classes that were instantiated unnecessarily.  It doesn't sound like this is a big hit.  And in the case of four, it's really not a big hit.  But I have had classes where I'm depending on seven or eight or nine different dependencies.  And I'm only using one or two.  A very typical place, a thing for this scenario for me is I use a lot of WCF.  I'm still very happy in the world of WCF.  And I use dependency injection from WCF services.  And some of my services have 10 or 12 operations.  And a lot of them retrieve data.  So I have a lot of different data repositories in my project.  That service may actually depend on 10 or 12 data repositories.  But the operation that I happen to decline happens to be calling.  May only need two of them.  So why do I need to instantiate the other 10 data repositories that I'm never going to  use during that call?  Object instantiation is not cheap.  Make no mistake about that.  It's heavier than reflection.  Because there's a lot of stuff that has to happen with instantiation.  I mean, you need to make sure that the heap has room for your object.  The heap doesn't have room for your object.  Then garbage collection needs to be run.  The heap needs to be compacted.  Generations have to be calculated.  There's a whole ton of stuff that has to happen just to get that object out on the heap.  And the pointer created on the stack.  So if I can avoid instantiating 10 objects and instantiate just the two that I need,  I'd prefer that.  So this technique is for on-demand instances.  It's basically called a service locator pattern.  Another term for it is a data abstract factory pattern.  Very, very similar.  Those patterns are not identical, but they are pretty similar.  And I'll show you how I do this.  I'm just going to run straight to the code so I don't run out of time.  Let me close this up.  And I'm going to come out here and go to commerce2.  Now take a look at commerce2.  Commerce2 is not receiving as dependencies the iBuildingProcessor, iCustomer, iNotification,  iLoggingProcessor.  It's receiving this iProcessor locator class.  And iProcessor locator class is an interface.  So it does get registered in the container to a class.  And the class that it gets registered to is this class right here.  This is an auto-fac processor locator because it's using the auto-fac container right from  there.  So I'm just forcing, I'm implementing one method here called getProcessor of t and returning  t.  Now I can inject the iProcessor locator into my class and ask it to create the interfaces  that I want because it's going to resolve them from the diContainer.  Now in this particular method, I'm not gaining anything because I'm doing all four.  But if I was calling another method that's only using one class, let's say the logging  processor, and that's all that I need, then I'm instantiating the other three unnecessarily  if I put them all up here.  So this is a technique that I use pretty heavily.  Has anybody ever watched any of my PolarCycorses?  Nobody has one person.  And three people.  Thank you ladies.  Thank you sir.  I'm going to give you guys a big prize that nobody else gets, okay?  Later on.  It's probably a lot of money.  Which course have you watched?  So the building multi-client and service oriented application.  That's the long one, right?  The one that's like 55 hours long.  Yeah.  I know it's long.  It's training.  It's called training.  I've watched my WCF course.  So that's another number one course, and that one is, I think it's 11 hours long.  But WCF's the topic that it takes me five days to teach it.  I do a 40 hour onsite class on that.  So these topics are big.  Anyway, my point was not to digress to the course.  In that course, I do this pattern.  This should look familiar to you.  Because this is what I'm doing with the business engine factory and the data repository factory.  The exact same pattern.  Exactly the same one.  So the reason that a lot of people think to say that this is an anti-pattern is because  they say that when you look at the, when your unit test looks at the constructor, all they  see is this and you'll never have any knowledge of what dependencies your operations are going  to use unless you look at the code for this dependency.  You have to decide whether that's a problem for you or not.  I don't have a problem looking at this and just seeing this.  I'm going to go into the code and say, okay, this method is using these four.  This method is using these two.  I have no problem with that.  It's for that only reason why this pattern, some people documented as an anti-pattern.  The problem is that when somebody puts that into a book, other people read it and they  think it's the Bible and all hell breaks loose.  That's why I don't read books.  Well, not tech books anyway.  Anyway, so this is the service locator pattern and it solves the problem really, really well.  Because now I can just ask for this one I want it.  You can test this with no problem.  I can create a mock for this and in that setup, I can do a mock of the processor locator  and set it up so that when the get processor is called with iBuildingProcessor, return  a mock of iBuildingProcessor.  So I don't lose anything in unit testing.  And I do all this for my plural site course.  I show you how to write the unit test for it.  It's doing it again, isn't it?  It's not the podium.  Huh?  No, I don't think it's me.  It's the guy back there.  He's messing with me.  He's got his hand on a little button.  He's going, watch this.  Ha ha.  Mess with the American.  All right, I got you.  All right.  To use this, it's no different.  You just saw what the commerce class looked like.  All I did was add the processor locator to the registration.  That's it.  I didn't change anything here except go resolve this.  I didn't change that.  I changed the commerce class.  I changed the dependencies of the commerce class and what the implementation inside  of it was, but everything outside of it, nothing has to be changed.  I didn't change whatever.  If something was calling the commerce class and it was not the container, that something  would have to change because that something went from sending four arguments to sending  one argument.  But this has not changed at all.  The container takes care of it all.  So here's another one, instance lifetime.  Instance lifetime is something that has been a problem.  And I don't exactly agree with the way these containers were designed to handle this.  But instance lifetime has to do with two things.  One of them is the singleton versus transient, which is fine.  That's easy.  The other one is the disposable stuff, which I'll talk about in a second.  Containers will let you register the associations, the classes, for conventional transient lifetime  or singleton.  What that means is that I can register any one of those things so that whenever anything  down the chain asks for an instance of iBuildingProcessor, they get a new instance of iBuildingProcessor.  I could also register it so that it's singleton pattern.  So that when they ask for iBuildingProcessor, the container will see if iBuildingProcessor  has been instantiated already.  If it hasn't, it goes through the process of instantiating it, but now it holds onto  it because it uses the same instance to feed any other requests for iBuildingProcessor.  You get built-in singleton capability here.  I'll show you that in a second.  That's one scenario for instance lifetime.  The other one's a little more hairy.  The other one is when anything that you're going to resolve from a container implements  the iDisposable pattern, the container is designed to hang onto that object even after  your use of it has long gone.  The explanation that I get about this is still a little weird for me because what I'm told  is that it does that because the container does not know when you're going to call dispose  on it, so it wants to hang onto it.  But if I'm done using the object, I'm usually under the assumption that I have called dispose  on it already, so I don't have to worry about that.  So I don't want the container hanging onto it.  And this can become a problem in a web application with memory leaks because now if you have,  if you're using a good example, it's WCF proxies, which implement iDisposable.  I tend to inject WCF proxies into MBC controllers or API controllers.  And WCF proxies are already associated to the service contract.  If you've ever done any WCF before, you've got a proxy associated to a service contract  because that's what it implements.  So it's already a perfect candidate for DI because I can register the proxy to the service  contract as just a class to an interface.  Then my MBC or web API controller can receive a constructor argument of type of the service  contract interface and it'll take care of instantiating the proxy.  But then after the request is done and that controller is gone because the web is stateless  and it doesn't hang onto controllers, the container, which is stateful, is hanging onto  that proxy because it implements iDisposable.  Even if I already called dispose on it.  So it doesn't make a whole lot of sense to me, but it becomes a problem because now you  start loading up memory with instances that are not used anymore and that's what causes  memory leaks.  So this apparently is a known thing.  I'm not going to say it's a known problem because the guys that write these containers  will tell you it's not a problem at all.  I consider it a small problem.  I think it could have been handled differently, but there is a solution for it.  And I'll show you what the solution for it is.  And every container has got their own different way of doing it.  Let me show you the singleton first.  I'm going to run real quick the lifetime scope here.  Oops.  Uh...  No, hold on.  What did I do wrong?  Did I screw something up when I messed up with this demo?  What was that now?  Oh, you're right.  You're absolutely right.  Thank you very much.  That means I got to get rid of that.  It was customer processor, right?  Now what's another way that I can fix that?  I'm going to comment this out, but how else can I fix it?  Just register it.  That's it.  Register it and let the container take care of what it needs to take care of.  Exactly right.  By the way, about my and any other authors' Pluralsight courses, Pluralsight's got a  booth out there.  So if you guys need a free 30-day subscription, they'll be more than happy to hook you up  with one.  Uh...  Keep in mind, all of the free 30-day subscriptions are only good for watching my courses.  Okay, check out what just happened.  Everything ran through, no problem.  Counter inside a class.  I have another class here called Singletester.  The counter is set to one.  I'm going to run it again.  Oops.  What's the counter set to?  It's set to one.  Why is that?  Huh?  No, it's not hard-coded, you smartass.  All right.  Which one is it?  Commerce 3.  There's Singletester, Display Counter.  Singletester's down here.  It just increments counter in the display counter and shows it.  So it's class-wide variable being incremented at the method, but both times it was one.  I've abstracted out so I can make it testable.  As you can see, it's coming to use it.  All I had to do was add it there.  And we're a Singletester.  There it is right there, and register it.  But each time it ran, it was set to one.  That's because every time that I ran it, the container is static in memory.  It only gets registered once.  But every time that I made a call to process order, as you can see, there's two calls right  here.  You just reinstantiate it, Singletester.  If I wanted to change that behavior, I can do this.  In AutoFac, all I have to do is add single instance.  Every container has its feature.  It's syntax, it's just going to vary.  It's going to change a little bit.  Say again?  No.  It holds it.  Absolutely.  As a matter of fact, I'll prove it to you.  Singletester is set to one.  It just incremented.  It's a class-wide variable, so the same instance of the class has been reused.  So the container is in charge of hanging onto it.  Now the pattern for fixing the disposable problem differs from container to container.  The way AutoFac does it is that AutoFac lets you temporarily create a kind of a subcontainer  of itself.  And then what it wants to do is it wants you to dispose that subcontainer because then  that's when any instances of dependencies that that container has given you, if any  of them are being held onto because they implement the IDisposable pattern, then the disposing  of the container is what gets rid of those instances.  But we obviously don't want to dispose our main container because we need that for the  rest of our application.  So AutoFac gives us this subcontainer kind of ability.  And all I did was build that functionality into another version of the processor locator.  So my original technique was not as cool, but at the same time I'm going to show you  yet another cool feature of AutoFac.  I know it sounds like I'm trying to sell AutoFac.  I'm not.  Use whatever you want.  They all have these features.  I'm just used to the syntax with this particular one.  But this is the processor locator that you saw before.  But what I'm doing is that when the processor locator is instantiating, I'm creating a scope.  That creation of a scope is creating the subcontainer that I'm talking about in the scope variable.  That scope variable is this lifetime scope.  And it's off that scope variable that the get processor is going to resolve my dependencies.  Because then when I'm finally done, from the hosting method, when I'm finally done using  these dependencies, I need to make a manual call to release scope.  And that subcontainer that I created gets disposed without touching the original container.  My original technique for creating the subcontainer was by going to the static class and creating  and doing a begin lifetime scope.  But I changed it because I wanted to show you one other thing.  There may be classes down the road that you write where you want to actually go to the  container and resolve something.  And you can do it this way, but there's a lot of people that have a problem with this.  And I can understand that.  Because what you're doing is that you're hard coding, you're coupling basically.  You're hard coding something concrete into a class.  Changing by saying go out to the container and get this, like in this case, I'm saying  begin lifetime scope, but it can also say program container.resolve to get something.  I'm still coupling to the container.  AutoFact has a cool feature, and I think most of them have this, where automatically, AutoFact,  the container itself has an abstraction that registers itself in itself, if you kind of  get that meaning.  I know it gets kind of weird, right?  But the AutoFact container itself implements an interface called ILifetimeScope.  And because that's automatically registered for you, AutoFact will resolve that for you.  So I've injected, because this class gets injected into commerce, I've injected ILifetimeScope  into here.  So when AutoFact resolves processor locator 2 and it sees this, it's going to say, okay,  what's ILifetimeScope registered to?  Oh, it's registered to me, the container.  So let me just take this container that exists, it's a Singleton container, and plug it into  there so I can have access to it, and then this class can now do a bunch of resolves,  does it do anything that it needs.  Now I can't do a begin lifetime scope from, I mean, I can't do a resolve right from this,  because this is not a subcontainer.  I still need to create that subcontainer.  This is the actual main container, the one that I created all the way the heck up here.  It just happens to be made available to you by the container itself.  Do you understand that weird twist of words that I'm using?  But it makes it, it's a pretty powerful feature.  When I learned about it, which is actually quite late, it was sometime in the middle  of last year, I didn't know you can do this, I had in several classes, I had this kind  of stuff here going on, and instead of scope, I would have this, right here, program.container.resolve.  And I changed all of that so that anywhere where I had that, I was just injecting this,  and now I can just do container.resolve.  And the nice thing about it is that I'm programming to an abstraction, so now I can test this  class if I wanted to, without being locked into a call to that static method, because  it's going off an interface.  So it's a cool feature that AutoFact has, and to the best of my knowledge, they all  have that to some capacity.  I know for a fact, who are the NINJEC users?  So NINJEC, I think it's called kernel, am I correct?  And NINJEC's got an ICernel interface, so I believe NINJEC, you can do that too.  You can inject the ICernel interface, and it's the same thing as injecting this.  You're injecting the container itself, so you can do resolves from it.  Did you give a hand up?  Nope?  Any questions?  Already did this?  Already did that?  Okay, there's other ways of doing registration, and I'm going to show you a couple of them.  We've got like five minutes left.  Is this the last?  It is the last.  They put me, you know I got off a plane this morning, and got into the tube, got to the  hotel, slept for one hour.  So if I mess things up, I may be giving you complete horseshit, okay?  It's just from lack of sleep.  All right, let me show you other ways that you can do registration.  I got a couple of demos on it.  I really wish that I had a full 75 minutes.  So this is assembly scanning.  If you set your classes up with nice naming conventions, which is always a good idea,  you decide what the naming conventions are.  You don't have to copy mine.  Just if you work with a team or you head up a team, naming conventions should be a my  way or the highway thing.  Which is don't let your developers run rampant on their own conventions.  Establish a set of conventions and ensure that they're followed.  And in my particular case, I have 100 dependency classes in this project, pretend.  But four of them are these processor classes.  I set up a naming convention for my processor classes.  The naming convention is that there's something, something, something, processor.  Very simple, just for demo purposes, right?  So what I did here is that instead of registering all the processor classes one at a time like  this, what I did here, I registered commerce because I had to.  And then I said register assembly types from the following assembly.  In this case, it's the executing assembly.  But you figure out how you need to get that assembly.  It can be off a type, like a type of something.assembly, any type in the assembly will do.  And I'm going to say of all the types in that assembly, I can use a lambda expression here.  Grab me the ones where the name ends with processor.  And then I'm going to register them as an interface.  Each one of them is going to be an interface.  What's the interface going to be?  Well, I'm going to lambda expression in and I'm going to grab for each of the types, whatever  type I happen to be in, get the interfaces for it and grab the interface that starts  with the letter I and ends in the name of the type.  Just following a naming convention.  So billing processor has I billing processor.  Customer data repository has I data repository.  In this case, it's just processor.  But you understand what I'm talking about when I say conventions.  By doing that, I can now add more processor classes and I never have to go in and register  them because I have this one technique that registers them.  That's one example.  And the demo is exactly the same as the other one.  It just shows you that it works.  This is another thing that all the containers have.  I only know how to use it in AutoFact, but I know that they all support modules.  As you can see here, I'm registering a type, but now I'm registering a module and that's  it.  Why is that?  Because I can now break out my registration in different classes.  This is that inherit from auto fact dot module, override the load and in there you get the  builder and now you just do your registration.  Whether it's this or hard code registration, whatever you want.  But now you can break them up.  And I have a module that's my business repositories.  I have a module that's my data repositories.  I have a module that's my WCF client proxies.  Just a nice way of breaking out your registrations.  And also these modules can now come from different assemblies.  WCF fact also has the ability that there's a new package called auto fact configuration.  And what it is is that it's a built in module whose job it is to go out to the config and  read config information and grab the type and interface from there.  So yet another way of registering it.  I see that red light.  Can I have two more minutes guys?  Well I know one person in particular wants to see this one.  So this is one to many.  Who was it that asked that question?  Who's you, right?  So here's building processor, customer notification, login processor.  And then here's an assembly type registration where I'm saying go to this assembly and register  anything that starts with the word plug-in, register it to ipostorder plug-in.  And I have three classes.  I post order plug-in.  I think they're just called plug-in one, two, and three if I'm not mistaken.  Here we go.  Plug-in one, two, and three.  How complicated is that?  Each one is simply just going to say plug-in number one executed number two and number  three.  So by registering multiple classes to one interface, I've just confused the situation  because now it's going to be up to my commerce class to do things the right way.  Because if commerce receives an injection of ipostorder plug-in, just one of them, it's  going to get auto-faxing to get confused.  And every container handles this separately.  I think one of the containers, I don't remember which one it is, will actually default to  the first of what is maybe many registrations to that same interface, it'll just take the  first one.  If you ask for one, it'll give you the one at the top of the stack.  Auto-fax does not do that.  Auto-fax will actually tell you, you must tell me which one of these you want.  And there's like a string identifier for it.  I can't remember how to use it.  All of them support this, which to me is the more common scenario, which is you inject  an I enumerable of that.  Because now you have all of the plug-ins, and now you can do with them whatever you  want.  And all I'm doing is iterating through the collection and calling in do something.  So it's a great technique for doing plug-in and modular architecture.  Does that answer your original question?  I'm going to skip that because it's rarely used.  I want to get to that one there.  Deterministic constructor injection.  This one's very cool.  And I cannot tell you, even if the other containers have this capability, I know that Auto-fax  does and it's helped me, and I know that Meph does because Meph actually forces it on you.  And what I'm talking about is the following.  I got a class with more than one constructor.  I'm surprised nobody's asked this question.  What happens if a class has more than one constructor?  Which one is it going to use?  Every container does things differently.  Auto-fax and Unity, and I think probably most of them, if not all of them, will actually  take the constructor with the most arguments and use that constructor.  But that may not always be the case, in my case here.  As you can see, this constructor has more arguments than this one.  Yet this one is used by, I don't know what the hell this is used by, somebody else is  using this constructor and sending in four integers in there.  But this one is depending on dependency injection.  However, the Auto-fax is going to, by default...  I should have had this commented out.  Sorry.  So as you can see, you can do so much more with these containers, more than what we have  time for.  But you could actually come up with default arguments in case it encounters this A argument,  put the number one in there, that kind of thing.  But watch this.  Eight.  Watch where it breaks.  It breaks here.  Now Auto-fax is automatically going to use this because it's got four constructor arguments  instead of three.  So it's the one with the most.  And it's going to send in the number one, because that's what I just told the container,  when it encounters A send in a one, B send in a one, and so on.  But then my call is going to go to process order, and it's going to come and run this  code.  And that's going to happen when it gets there.  It's immediately going to break.  Why is it going to break?  Because processor locator is null.  Because that came in through the other constructor.  So the point of this last exercise is how do we get deterministic constructor injection?  Something that if you've used mef, who's used mef before?  MEF.  So you know mef has got the importing constructor argument.  So in mef, you're forced to tag the constructor that you want to use, you have to tag it with  that.  And for people that think that's dirtying up your code, it actually helps you quite  a bit because it automatically solves this problem.  Because you told mef, I have 15 constructors on.  It got help you if you really got 15 constructors.  But I got a boatload of constructors.  This is the one that I want the container to use.  Well I want to mimic that scenario here.  So I want to do it by using my own very appropriately called awesome constructor attribute.  So what is this awesome constructor attribute?  Does the awesome constructor attribute solve the problem for me?  It doesn't do anything.  A constructor is only as good as that which looks for it.  The constructor itself is not doing a damn thing.  But something has to be looking for awesome constructor attribute.  So what is looking for it?  Model fact has this concept of a constructor finder.  So I wrote awesome constructor finder and I have to implement the find constructors.  This is the type that is about to be resolved.  In my case commerce.  I do whatever I need to do to determine what constructor to use.  In my case, I'm looking for the constructor that's got that attribute.  If you want to use the first constructor, go ahead.  If you want to say if it's a full moon and it's on Tuesday, use the third constructor  just to mess with somebody, you can do that too.  I say use the one that's got that attribute on it.  So now that I got this constructor finder, I can install it like this.  Do my registration but then add here find constructors with an instantiation of new  constructor finder.  And that's it.  That solves the whole problem because now when I run this, the constructor that it breaks  in is that one.  And my code continues to run and everything is fine.  And there's my plug-ins, by the way.  So guys and gals, this is all we have time for.  This is actually the last demo without going into the projects.  But the projects are here for you to mess around with.  I'm at your disposal.  Feel free to email me, Twitter me, whatever if you need help with this.  It's this whole usage scenarios auto fact section at the end here.  You got an MBC application, WCF web forms and WPF all using auto fact and showing you  how to use dependency injection.  In WPF, I show you how to do it with view models, in MBC, I show you how to do it with  controllers.  So it's some pretty cool demos.  I wish we had time for them.  But the code is all yours.  I give the code to the people here.  I don't know if they have a site for it or not.  But I have a place where they will be up on and I can probably do it as early as tomorrow.  I don't have to wait until I get home.  But go to my website, my company website.  There's a downloads link on there and you'll see a list of conferences.  NDC will be the most recent one.  And you'll just see the two sessions that I'm doing here on there.  And you got the slides, the code, everything.  The demos are laid out pretty good.  So I think you can get a lot from them.  I'm speaking again on Friday morning and then I'm flying out Friday afternoon.  I'm doing a talk on how to play nice with ASP.net, MBC, and Angular.  Any Angular junkies here?  That's it.  What are the rest of you use?  Nothing?  Anyway, come see me again.  I hope you enjoyed this.  Please give me an eval.  Hopefully there's no red ones left.  Actually, I shouldn't have said that.  That means that they've been used.  But give me an honest eval.  And we use this information quite religiously.  So please don't forget.  And that's it.  Enjoy your day.  Have a great rest.
End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_0_647.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_648_1295.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_1296_2351.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_2352_13811.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_13812_15347.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_15348_15515.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_15516_18227.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_18228_18323.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_18324_25007.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_25008_26471.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_26472_31679.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_31680_33215.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_33216_34343.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_34344_34403.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_34404_40823.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_40824_41003.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_41004_41051.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_41052_41123.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_41124_41207.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_41208_41351.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_41352_41483.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_41484_41555.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_41556_41771.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_41772_42011.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_42012_42131.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_42132_42203.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_42204_42263.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_42264_42311.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_42312_42359.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_42360_42527.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_42528_42959.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_42960_43115.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_43116_43751.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_43752_45167.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_45168_45383.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_45384_49979.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_49980_53723.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_53724_54731.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_54732_55079.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_55080_57335.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_57336_57407.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_57408_57455.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_57456_57827.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_57828_57887.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_57888_58043.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_58044_58175.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_58176_58307.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_58308_59015.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_59016_60695.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_60696_62123.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_62124_62171.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_62172_62555.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_62556_62807.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_62808_63623.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_63624_65459.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_65460_75455.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_75456_75791.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_75792_75863.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_75864_77255.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_77256_77399.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_77400_77627.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_77628_78155.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_78156_79871.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_79872_86855.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_86856_87395.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_87396_88631.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_88632_88919.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_88920_88979.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_88980_89951.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_89952_95579.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_95580_96827.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_96828_98267.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_98268_98819.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_98820_98891.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_98892_99359.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_99360_99419.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_99420_99587.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_99588_103367.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_103368_103439.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_103440_107051.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_107052_108059.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_108060_108167.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_108168_108251.png End-to-End_Dependency_Injection___Writing_Testable_Software_-_Miguel_Castro_108252_109781.png