Patterns

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The latest Enterprise Library information can be found at the Enterprise Library site.

In software architecture and development, a pattern is a description of a recurring problem that occurs in a given context and, based on a set of guiding forces, suggests a solution. The solution is usually a simple mechanism: a collaboration between two or more classes, objects, services, processes, threads, components, or nodes that work together to solve the underlying architecture or development challenge.

Patterns are useful to developers and architects because they:

  • Document simple mechanisms that work.
  • Provide a common vocabulary and taxonomy for developers and architects.
  • Allow solutions to be described concisely as combinations of patterns.
  • Enable reuse of architecture, design, and implementation decisions.

The Enterprise Library application blocks use the following patterns (among others):

  • Factory design pattern. This is a creational pattern that uses a special type of object to create other objects.
  • Plug-in pattern. This pattern extends the behavior of a class by allowing extensions to plug into an abstract class that, in turn, plugs into a core class. This creates a new subclass that includes only the capabilities required in the given context.
  • Dependency Injection pattern. With this pattern, you can inject objects into a class, instead of relying on the class to create the object.

For more information about patterns, see Microsoft patterns & practices and the PatternShare Community Web site.

Factory Pattern

The Factory pattern is a software design pattern of the creational type (that is, it uses one abstract entity to create another). The Enterprise Library application blocks make extensive use of the Factory pattern. For example, in the Caching Application Block, the CacheFactory initializes an instance of the CacheManager object. The CacheManager creates a CacheManagerFactory object, which in turn creates a Cache object. The Cache object holds an in-memory representation of the data in the backing store. After the Cache object is created, applications can make requests to the CacheManager object to retrieve cached data, add data to the cache, and remove data from the cache. For more information, see Design of the Caching Application Block.

The Data Access Application Block uses the Factory pattern in a similar manner. The client code calls the static CreateDatabase method on the DatabaseFactory class to create instances of the Database object. For more information, see Design of the Data Access Application Block.

For more information about the Factory pattern and its use in the .NET Framework, see Exploring the Factory Design Pattern on MSDN.

Plug-in Pattern

The Plug-in pattern is a software pattern that creates an object instance of an interface at run time. The Plug-in pattern extends the behavior of an existing class so that it can be used for a more specific purpose. It differs from using class inheritance, where behavior is altered or overwritten, or configuration where behavior modification is limited to the capabilities of the defined configuration options.

With the Plug-in pattern, the modified behavior (the plug-in) connects to an abstract partial class, which, in turn, connects to the core class. The plug-in uses this interface to implement methods called by the core class and can also call new methods at the core class.

Dependency Injection Pattern

The Dependency Injection pattern allows you to inject objects into a class, instead of relying on the class to create the object. This is particularly helpful in situations where you want to decouple the details of a particular implementation or deployment from your application code. The Dependency Injection pattern decouples services or other code that an application might be dependent on from the application itself and packages it in a container. Then, the responsibility for handling the code interdependencies—including object creation and linking—are removed from the objects themselves and transferred to another entity. Unlike with the Factory pattern, with the Dependency Injection pattern, code in containers can be shared by multiple applications.

The System.ComponentModel namespace is a Microsoft implementation of the Dependency Injection pattern. In the Enterprise Library, the ObjectBuilder implements the Dependency Injection pattern.

For more information about the Dependency Injection pattern, see Inversion of Control Containers and the Dependency Injection Pattern.

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The latest Enterprise Library information can be found at the Enterprise Library site.