Sharepoint applications - Architecture and Design lessons learned

In this blog post I’m going to highlight some of the design and architecture lessons that I’ve learned so far. In future posts I’ll be drilling down in some of the areas and present concrete examples.

So here is my list so far:

1) Do not forget standard/proven design and architecture patterns just because you are using SharePoint.

SharePoint should be seen as another layer in your 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.

2) 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.

3) 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 you 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.

4) 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).

5) Empower business users but try to keep them in their comfort zone.

I know that this sounds like a sales cliché but it’s actually one of the main SharePoint selling points. You should ear this sentence echoing in the back of your mind every time you are talking to a customer. This will help you making better decisions and keep your customers happy. Here is an example:
a. You are responsible for the architecture and design of a brochureware site for a major financial institution. One of the main reasons for them to adopt SharePoint was to give more control to business users. You decided to base the site on the out of the box publishing site definition and you are just about to test your first content page (which is using the out of the box Rich HTML editing control).You look at the generated html code and suddenly freeze. Your heart starts pumping faster and you cannot believe on what your eyes are telling you; the HTML code generated by the control is appalling. Your professional pride kicks in and tells you that you cannot be responsible for code like this.

What do you do?
i. Talk to the customer about the problem and suggest replacing the control with a “professional quality” third party editing control (they would need to agree the extra costs).
ii. Tell the customer that you cannot be responsible about the quality of the codegenerated by the control and ask them to make a decision. You can point out that, although the quality of the generated code is far from ideal, it can be a viable option as long as they are not concerned with accessibility issues.
iii. Tell the customer to continue to use the control and teach them how to improve the code by showing them the control’s HTML view.
Option (iii) is the least appealing one because it will require your business users to step out of their comfort zone and learn something that they shouldn’t need to for their day to day jobs (unless they are technical minded and do not mind the learning curve).