SharePoint Lessons Learned – Don’t forget to use proven design patterns and practices
SharePoint should be seen as another layer in the technology stack that your code will interact with. But just because you are using this layer you should not forget to follow good and proven design practices. The following points describe some of the principles that sometimes seem to be forgotten when using SharePoint:
Create a data access layer to access your lists.
After all you would be doing this if you were programming against a database table so why not do the same for a SharePoint list. The last thing you want is to have several components of your application accessing the same list in several different ways. If the list schema, name or location changes then you would need to change the code in every component that uses that list (this could be acceptable for small proof of concept applications but not for enterprise applications). In a future post I’ll be giving an example of designing and coding a simple SharePoint data access layer.
Use SharePoint lists to store configuration data. Create a configuration site, on your site collection, containing all the configuration lists
Before SharePoint all configuration needed by your applications resided in a data store (normally a database). You then needed to build a UI to allow power users and/or administrators to change that information. You also had to implement security mechanisms to make sure that only the users with the correct permissions were allowed to change or access that data. With SharePoint you can accomplish all of that with out of the box functionality without writing a single line of code.
You can also adopt the same principle for structured content. For example let’s say that you want to create a very simple top navigation menu (like the one on the top right corner of this page) and allow your users to add new links or edit existing ones. You could create a TopNavs list on a “/config” site under your site collection with “Name” and “URL” columns. You could then create the menu using a simple ASP custom control and bind it to the TopNavs list. I’ll be showing how to do exactly that in a future post.
Do not forget about databases
Just because you are using SharePoint and have all of those nice lists that you can easily create and configure it doesn’t mean that you should stop using databases (disregarding the fact that SharePoint is actually storing all of the list data on a database). You should always ask yourself the reasons why you should use a SharePoint list instead of a database table. Remember – SharePoint is a service layer – so if you are not using the services provided by that layer then perhaps you should be using a database table instead. SharePoint lists also have greater limitations than database tables (see this Microsoft document for more information on those limitations).
Plan the deployment process early and be very careful with tools like SharePoint Designer
Don’t assume that, just because you can use the server that sits under your desk to develop fantastic and feature rich SharePoint sites using SharePoint Designer, that you will be able to easily transform them into enterprise class applications that will run on your corporate servers. Sites developed using SharePoint Designer are normally difficult to move between environments (development, test and production) and can bypass all the version control mechanisms your organisation already has in place to develop other types of applications (ex. TFS or VSS). So get familiar with the SharePoint Designer limitations before you start using it (don’t make everything into a nail just because you have a new shiny hammer).