Design Patterns for developing SharePoint 2010 Solutions

Last week at the European SharePoint Conference, I talked about a few different design patterns that you can use when you develop custom solutions for SharePoint 2010, to make sure that your code is easy to maintain, extend and test.

We specifically talked about the following patterns:

• Repository
• Model-View-Presenter
• Service Locator

Each of these patterns offers a solution to different design issues that you might encounter when creating code based solutions. Our development team has successfully applied these patterns on several client projects where a fair amount of custom development was needed. However, applying the patterns will require some initial extra work and requires the developers in the team to be somewhat familiar with the patterns. So only apply them when you really see that you can get some benefit out of them.

Please check out the slides and sample code from the session.

To get started with the sample solution, please do the following:
• Download and unzip the package
• Open the SharePointEurope.DesignPatterns4 solution (the final solution where all patterns have been applied, as well as the configuration settings management)
• Deploy the SharePointEurope.Dependencies package to ensure that the common service locator library and application foundations are deployed to the GAC
• Create a site collection and deploy the SharePointEurope.DesignPatterns4 project to the site.
• Generate a Google Map Key for the host name of your web application and go to the configuration list (/Lists/Microsoft_Practices_SharePoint_ConfigList) and set this value.
• Create a few hotels in the Hotel list (/Lists/Hotels)
• Add the hotel finder web part somewhere and try it out

A few notes regarding the things we discussed at the session:

Repository implementation
There are many different ways to implement the repository pattern in SharePoint. In my sample implementation you have two options when creating the repository: Either provide the repository with a specific SPWeb object in the constructor, or use the context of the current web site. It’s important to make sure that you can use your repository from contexts where SPContext.Current is not available, such as i.e. timer jobs. Another option is to use configuration settings to provide an URL to a centrally located site where the hotels list is located – which is useful if you want to use the repository on other sites than where the list exists.

If you look at how the training management application in SharePoint Guidance 2007 is implemented, you can see that they use a slightly different approach. In that implementation, you need to provide the repository with an SPWeb object in each of the repositorys data access methods.

The problem with this approach is that your repository interfaces becomes cluttred with specific dependencies to SharePoint. An important goal of the repository pattern is that you should make yourself independent of exactly how the data is stored. And if you decide to change the data storage from SharePoint to i.e. SQL Server, you would need to not only change the implementation of the repository, but the interfaces and all the code that depends on it as well. In my opinion, it’s much better to let the repository get the data context it needs internally instead, or to use dependency injection to configure exactly how it’s provided to the repository. Here you could benefit quite a lot from using a proper dependency injection framework rather than the SharePoint Service Locator.

List based configuration
During the demo I showed you a simple example on how you could generate a configuration list and use it to store, retrieve and update settings. If you decide to go for the list based approach, I encourage you to check out the List Based Configuration Quickstart that’s available as a part of the SharePoint Guidance 2010 package. It’s a bit more refined and basically implements the same interfaces as the property bag-based configuration classes do. This makes it possible to use lists to store you configuration settings for any level of the farm (farm, web app, site collection or web) by specifying the path to a centrally located site collection where the settings are stored.

Using Application Foundations in sandboxed solutions
I got a few questions after the session about using the Application Foundations Library in sandboxed solutions.

The application settings manager can be used in sandboxed solutions, but there are a number of limitations of course. You can read more about using the application settings manager in sandboxed solutions here: http://msdn.microsoft.com/en-us/library/ff798449.aspx

I haven’t tried the SharePoint Service Locator in a sandboxed solution yet – if anyone has done that, I would be happy to hear about your experiences. Otherwise, there are plenty of other options for implementing the pattern, including implementing your own simple code-based service locator.