When Should I Use the SharePoint Service Locator?

  • Article

You can use the SharePoint Service Locator within server-side code that runs in your SharePoint environment. The SharePoint Service Locator is particularly useful when:

  • You want to develop modular, flexible classes that do not need to be edited and recompiled if an internal or external dependency is updated or replaced.
  • You want to be able to unit test your classes using mock objects or stubs. The Service Locator allows you to substitute the real implementation of a dependency with a test implementation.
  • You want to remove repetitive logic that creates, locates, and manages dependent objects from your classes.
  • You want to develop code that relies on interfaces whose concrete implementation is not known, or not yet developed, at compile time.

You can use the SharePoint Service Locator in most SharePoint development scenarios. To use the SharePoint Service Locator, your code must either:

  • Run in the SharePoint context (for example Web Parts).
  • Have access to the local SPFarm object (for example timer jobs, feature receivers, console applications running on a Web front end server, and other types of full trust farm solutions).

Note

What do we mean by code that runs in the SharePoint context? When your code is invoked synchronously by a user action, such as clicking a button on a Web Part or selecting an item on the Site Actions menu, you have access to an SPContext object. This represents the context of the current HTTP request, and provides information about the current user, the current site, and so on. SharePoint solutions that are not invoked synchronously by a user action, such as timer jobs, service applications, and feature receivers, are not associated with an HTTP request and as such do not have access to an SPContext object. These solutions are said to run outside the SharePoint context.

Benefits of the SharePoint Service Locator

The SharePoint Service Locator provides the following benefits:

  • It makes a codebase less fragile by compartmentalizing dependencies, because classes consume interface implementations without requiring knowledge of the implementing classes.
  • It creates a pluggable architecture that allows you to replace interface implementations with updated or alternative versions, without requiring you to edit and recompile consumer classes.
  • It allows your code to use different implementations of the same interface, based upon selection logic. This allows you to change the behavior of your solution, based on the execution context.
  • It centralizes dependency management in the service locator. This allows developers to replace multiple direct dependencies on specific classes with a single dependency on the service locator.
  • It ensures that interface implementations are used consistently across an application, by removing the need for dependencies on specific classes.
  • It supports more modular applications where portions of the codebase can independently grow and evolve as business needs change.
  • It allows services to be replaced with mock objects or stub implementations for unit testing.

Disadvantages of the SharePoint Service Locator

While using the SharePoint Service Locator in your solutions is generally beneficial, you should be aware of the following consequences:

  • There are more solution elements to manage initially. However, as your codebase grows you should benefit from less code redundancy and improved organizational structure.
  • You must write additional code that adds service references to the service locator before your objects can use it, and you must implement interfaces on your services.
  • You may be using configuration data to define run-time relationships. If the configuration data is corrupted, your run-time relationships will break. If the service locator does not find the definition for an interface, it will throw a NotRegisteredException.