3 Design Patterns SharePoint Developers Should Know

SharePoint is a large platform with a decent-sized learning curve. So it's easy, as SharePoint developers, to get caught up in the details of the platform and forget to employ tools such as design patterns in our code. Design patterns have the same benefits in SharePoint as they do in any other programming environment. Let's take a quick look at three well-known design patterns that can help us.

Model-View-Presenter Pattern

Essentially, the premise of the Model-View-Presenter (MVP) pattern is to separate application logic from view (UI) logic, buying us at least two important benefits. First, automated testing of application logic becomes easier by removing the dependency on the view. Second, maintenance and readability of our code are both improved by cleanly separating these concerns.

As the pattern's name implies, it has three parts. The model is the business logic and application data; the view is the UI component that interacts with a user, such as a Web Part, page, or dialog box; and the presenter is the go-between that connects the two. User requests to the view are forwarded to the presenter, which in turn performs actions on the model. The presenter also listens to the model for relevant events and updates the state of the view as needed.

For testability, an interface is defined for the view, and the presenter refers to that interface rather than the actual view. The view can then be swapped out at test time as needed. This approach can be useful for unit testing the logic behind Web Parts and other UI elements in SharePoint. For a summary of this pattern along with some code samples, see the MSDN article "The Model-View-Presenter (MVP) Pattern."

Service Locator Pattern

To understand the Service Locator pattern, we must first recall the technique of dependency injection in object-oriented programming. To summarize, suppose we have a consumer object that depends on a service provider object (the latter might be something such as a database provider, for example). The goal of dependency injection is to decouple the two and make it easy to swap out providers. It's called dependency injection because the consumer holds a reference to an abstract implementation of a service provider at compile time (e.g., a database provider), and a third component "injects" a concrete implementation (e.g., an Oracle database provider) into the consumer at runtime.

The Service Locator pattern is a dependency injection technique that works by employing a "locator" object to maintain a list of registered service providers. At runtime, a consumer requests a service it needs, and the locator object locates and returns an instance of that provider. The consumer doesn't need to know the implementation details of the service provider, nor must it involve itself in managing the provider's lifecycle.

This pattern is readily accessible to us thanks to the code library that ships with the SharePoint 2010 Patterns and Practices guidance available in the MSDN Library. The library lets us register a service provider at the farm or site-collection level and retrieve it later using the SharePointServiceLocator class. Swapping out providers is as simple as registering a new provider in place of an existing one.

Model-View-ViewModel Pattern

As Paul Stubbs pointed out in "3 Technologies SharePoint Developers Must Know," SharePoint developers would do well to learn Silverlight. In addition to letting us create richer UIs in SharePoint, Silverlight skills carry over to other platforms such as ASP.NET and Windows Phone 7. If you plan to learn Silverlight, you should also learn the Model-View-ViewModel (MVVM) design pattern.

MVVM was designed with goals similar to the MVP pattern. It lets developers cleanly separate business logic from view (UI) logic, making automated testing and long-term maintenance easier. The difference is it was designed specifically for Windows Presentation Foundation (WPF) and Silverlight, both of which tend to use a data binding–centric approach to UI development. In terms of implementation, MVVM shares some similarities with MVP. However, there's no view interface, and the presenter is replaced with a "view-model" class that uses data binding to communicate with the view. For a great introduction to the pattern, see the Channel 9 video of John Papa, Silverlight and WPF architect at Microsoft.