次の方法で共有

Declarative Context Adapters

  • [アーティクル]

The first post in this series introduced the problem of accessing IoC container features dynamically.

We brushed over two common patterns:

  • Global Container (or Static Service Locator)
  • Injected Context

Before we move on from this topic, I'd like to look at one more pattern in this theme that may not be in common use, but deserves some attention anyway.

This pattern I've labeled Declarative Context Adapter, and it builds on the strengths of Injected Context while moving from imperative implementation to declarative configuration.

Problem

After composition, a component requires dynamic access to features of the container that hosts it (the context.)

Commonly, this involves dynamically creating or locating instances from the container (e.g. see ControllerProvider in this article.)

Solution

  • Provide a domain-specific interface to the required functionality.
  • Describe how this interface should interact with the container using metadata or configuration.
  • A compliant implementation is supplied based on the metadata.

Example

One example of a Declarative Context Adapter is the generated factories feature of Autofac.

This feature uses .NET delegate types as the 'domain-specific interfaces'. The Shareholding.Factory delegate type below plays this role:

image

In this example, we want invocations of the Factory delegate to return instances of the Shareholding class created and wired up by the container. This example is a bit contrived, since usually there is some abstraction involved, but hey, it is just an example :)

The ContainerBuilder's method-chaining API allows the mapping between the delegate to the container's Resolve() method to be specified:

image

This is specified via the RegisterGeneratedFactory() method.

The only declarative configuration in this example apart from the delegate type itself, is the TypedService parameter that tells Autofac which service from the container should be returned whenever the delegate is invoked.

(Additional configuration options can describe parameter mappings for the delegate parameters, however these aren't available in the current release builds.)

Other components that need to instantiate Shareholdings can now have instances of Shareholding.Factory injected into them.

Discussion

To call this technique a 'pattern' is a bit premature, since the Autofac feature is the only implementation you can put your hands on.

The same functionality could  be implemented on different containers, perhaps via AOP. It would also be preferable to support interfaces as well as delegate types.

While the examples have been related to instantiation or service lookup, context adapters could be defined for other container features like lifetime management or even component registration. Anywhere that Injected Context is used, it should be possible to generate a configuration-driven alternative.

Source Code

The tiny example from above can be downloaded here if you'd like to experiment with it.

Comments

  • Anonymous
    January 04, 2009
    PingBack from http://www.alvinashcraft.com/2009/01/04/dew-drop-january-4-2009/

  • Anonymous
    January 07, 2009
    Found some other examples: similar functionality based on interfaces in Castle MicroKernel's TypedFactory facility, and according to some mailing list threads it seems like Spring has similar support too (not sure what it is called though.) Guess we can call it a pattern after all :)