This project is read-only.

Conceptual Scenarios

This section will explore some conceptual scenarios that compare how applications may use DI containers and service locators compared to how applications may use them with Drill.

Scenario 1a

This scenario compares how an application couples to a DI container (A) versus how the application would look when using a Drill dependency resolver (B).

Drill-ConceptualScenarios-Scenario1a.png

In the scenario above, application A is directly coupled to the DI container and application B is coupled to Drill using a dependency resolver to integrate the functionality of the DI container. In this scenario, Drill just looks like a simple interface, not unlike the Common Service Locator. Drill is much more as you will learn.

Scenario 1b

This scenario is basically the same as Scenario 1a but the application already uses the Common Service Locator.

Drill-ConceptualScenarios-Scenario1b.png

Application B shows how the Common Service Locator can also be used with Drill by installing the Drill.Integration.CommonServiceLocator NuGet package and using the ServiceLocatoradapter class to adapt Drill's IDependencyResolver interface to the Common Service Locator's IServiceLocator interface.

Scenario 2a

This scenario compares how application A couples to a DI container and a service locator versus how the application would look when using a Drill dependency resolver (B).

Drill-ConceptualScenarios-Scenario2a.png

Application A must use and manage separate interfaces and objects for the DI container and the service locator. Application A is tightly coupled to the DI container and the service locator. Application B uses a Drill dependency resolver (and is tightly coupled to Drill's IDependencyResolver interface) but is loosely coupled to the DI container and service locator. Also notice that application B uses a single dependency resolver instance to resolve objects from both the DI container and the service locator. Only one object reference (to the Drill dependency resolver) must be managed by the application.

Scenario 2b

This scenario is basically the same as Scenario 2a but the application already uses the Common Service Locator.

Drill-ConceptualScenarios-Scenario2b.png

One may think that application A's usage of the Common Service Locator solves the coupling issue, which it does but it stall has to manage multiple references to separate IServiceLocator instances, one to manage the DI container and another to manage the service locator. Application B is using a single Drill dependency resolver which is fronted by the Common Service Locator's IServiceLocator interface. Application B only manages one reference which is used to resolve objects from both the DI container and the service locator.

Scenario 3

This scenario shows a high-level conceptual diagram of a Drill dependency resolver using multiple DrillBits to resolve objects from multiple resolvers (more than one DI container, service locators and other object resolution sources).

Drill-ConceptualScenarios-Scenario3.png

Drill allows an application to bind only to the Drill IDependencyResolver interface and configure the underlying resolution sources. This is useful when you do not wish to commit to a DI container or service locator framework because it allows you to change out that framework for another without disturbing the code you have already written. When integrating other applications, you may find yourself with two or more DI containers or other service locators. In this case, Drill allows you to combine these systems under a single interface using a single dependency resolver instance while decoupling the other systems from the application until the work can be performed to refactor the code to use a single underlying system.

If an application already binds to the Common Service Locator's IServiceLocator interface, it can simply use the Drill adapter to switch to use Drill instead without further disrupting the codebase. If the application is already using some other interface (similar in usage to the Common Service Locator), an adapter can easily be created to interface with Drill. Drill is very extensible at multiple levels.



Last edited Nov 24, 2012 at 6:12 PM by wreynolds, version 8

Comments

No comments yet.