ASP.NET MVC: Andare oltre il 100% (Web@work)

Editor's Notes

• #15: 2 problemi: test e limitazionefunzionalità
• #16: Possibilità di far fare al metodocose diverse (sms, email, ecc.)Possibilità di testareilmetodo
• #17: The service locator pattern says that inversion of control is achieved by having components get theirdependencies through an external component known as the service locator. Sometimes a servicelocator is a very specific interface, with strongly typed requests for specific services, and sometimesit may show up as a very generic way to request services of any arbitrary type.
• #18: In this case, when you need an implementation of IServiceLocator, you know to callGetMessageSender. The method returns exactly IMessageSender, so you won’t need to castthe result.You’ll notice that I’m showing the service locator as an interface here rather than as a concrete type.Remember that one of your goals is to reduce the tight coupling between components; this includesthe coupling between the consumer code and the service locator itself. If the consumer code is codedagainst IServiceLocator, that means you can substitute alternative implementations at run time asappropriate. This can have tremendous value in unit testing.Now if you re-write NotificationSystem in terms of the strongly typed service locator, it mightlook like this.We’re assuming that anybody who creates an instance of NotificationSystem will haveaccess to a service locator.
• #19: public interface IServiceLocator{IMessagingService GetMessagingService();}
• #20: In this case, when you need an implementation of IServiceLocator, you know to callGetMessageSender. The method returns exactly IMessageSender, so you won’t need to castthe result.You’ll notice that I’m showing the service locator as an interface here rather than as a concrete type.Remember that one of your goals is to reduce the tight coupling between components; this includesthe coupling between the consumer code and the service locator itself. If the consumer code is codedagainst IServiceLocator, that means you can substitute alternative implementations at run time asappropriate. This can have tremendous value in unit testing.Now if you re-write NotificationSystem in terms of the strongly typed service locator, it mightlook like this.We’re assuming that anybody who creates an instance of NotificationSystem will haveaccess to a service locator.
• #21: Why might you choose a weakly typed locator? It allows you to fi x many of the downsides of thestrongly typed locator; that is, you get an interface that can create arbitrary types without knowingabout them ahead of time, and it reduces your maintenance burden because the interface is not constantlyevolving.On the other hand, a weakly typed locator interface doesn’t really communicate anything aboutthe kinds of services that might be requested, and it doesn’t offer a simple way to customize the creationof the service. You could add an arbitrary optional array of objects as “creation parameters”
• #22: Non è il componente che cerca verso l’esterno un servizio che risolva le dipendenze ma è la chiamata dall’esterno che fornisce al componente la risoluzione delle dipendenze.The dependency injection (DI) pattern is another form of the inversion of control pattern, whereinthere is no intermediary object like the service locator. Instead, components are written in a waythat allows their dependencies to be stated explicitly, usually by way of constructor parameters orproperty setters.Developers who choose dependency injection over service location are often making a consciousdecision to choose transparency of requirements over opacity. Choosing the transparency of dependencyinjection also has signifi cant advantages during unit testing, as discussed in the next chapter.
• #23: The most common form of dependency injection is called constructor injection. This techniqueinvolves creating a constructor for your class that expresses all of its dependencies explicitly (asopposed to the previous service location examples, where your constructor took the service locatoras its only constructor parameter).In this code, the fi rstbenefi t is that the implementation of the constructor is dramatically simplifi ed.The component is always expecting whoever creates it to pass the required dependencies. It onlyneeds to store the instance of IMessagingService for later use.Another benefi t is that you’ve reduced the number of things NotificationSystem needs to knowabout. Previously, it needed to understand service locators in addition to its own dependencies; now,it is focused solely on its own dependencies.The third benefi t, as alluded to previously, is this new transparency of requirements. Any code thatwants to create an instance of NotificationSystem can look at the constructor and know exactlywhat kinds of things are necessary to make NotificationSystem function. There is no guessworkand no indirection through the service locator.
• #24: A less common form of dependency injection is called property injection. As the name implies,dependencies for a class are injected by setting public properties on the object rather than throughthe use of constructor parameters.This class expects any consumers to provide you with your dependenciesvia properties rather than the constructor.The InterestingEventHappened method is now slightly dangerous. It presumes that the servicedependency has already been provided; if it hasn’t, then it will throw a NullReferenceException.You should update the InterestingEventHappened method to ensure that it has been providedwith its dependency before using the service.It should be obvious that you’ve slightly reduced your transparency of requirements here; it’s not quiteas opaque as using the service locator, but it’s definitely more error prone than constructor injection.With this reduced transparency, you’re probably wondering why a developer would choose propertyinjection over constructor injection. Two situations might warrant that choice:‰ If your dependencies are truly optional in the sense that you have some fallback when theconsumer doesn’t provide you with one, property injection is probably a good choice.‰ Instances of your class might be created in such a way that you don’t have control over theconstructor that’s being called. This is a less obvious reason. You’ll see a couple of examplesof this later in the chapter when we discuss how dependency injection is applied to view pages.In general, developers tend to favor using constructor injection whenever possible, falling back toproperty injection only when one of the preceding reasons dictates. Obviously, you can mix bothtechniques in a single object: put your mandatory dependencies in as constructor parameters, andyour optional dependencies in as properties.
• #25: A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
• #27: A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
• #28: A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
• #29: A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
• #30: A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.