Monday, December 20, 2010

SharePoint 2010 Development Patterns and Practices


I would highly recommend reading the Developing Applications for SharePoint 2010 best practices that have been written by the Microsoft Patterns and Practices team. In this blog posting I am going to capture my notes as I read this.

Part 1 - Application Foundations for SharePoint 2010

This first section covers several basic concepts. Is basically a discussion for three reusable components that have created as part of this effort and I would seriously recommend bringing them into your custom solutions.

  • First they created a Service Locator pattern which will help you more layered architectures instead of embedding all your logic into a web part.
  • Second they create an Application Setting Manager which follows several best practices for using config data for you custom solutions.
  • Third they have provided a SharePoint Logger that provides you great utility to have better application logging within SharePoint.

There is also a detailed discussion on creating solutions and custom code that are testable. Over the past few years, I have seen a lot of custom SharePoint solutions that are not as testable as they should be. I think the real point is that you should continue to use the same custom software development practices with SharePoint as you would if you were creating a custom application. It seems like so many solutions I have seen have forgotten this.

Part 2 - Execution Models in SharePoint 2010

If you are a developer, architect or technical team leader – this section is an absolute must read. I was so happy to see this written because I cannot tell you how many times while I was doing SharePoint 2003 and 2007 projects that we would have to figure this out every time because there was no good guidance.

They basically break it down into understanding two aspects. The first being the execution environment which is basically where will the DLL you create being deployed (i.e. the bin, gac). Understanding this has several Code Access Security (CAS) considerations you must understand. The second is the execution logic which means understanding how will your custom code be invoked. Code can be invoked in a web part, timer job, workflow, etc. Understanding these aspects will give you a fundamental understanding of how SharePoint works underneath the hood.

In the Farm Solutions section there is a great discussion describing the process flow of how libraries and loaded into memory. This documentation was not available in the SharePoint 2007 timeframe and we had to figure this out ourselves. The discussion specifically discusses loading custom dlls into either the Bin or the GAC and the design decisions you should make around this. I still stand firm that it is best to deploy to the Bin mostly for security reasons.

There is a good justification made here for Sandboxed solutions. The basic point is that to deploy a standard SharePoint WSP solution requires administration permission levels and access to the SharePoint box, which has to be tightly controlled for production. Developers should never have access. Sandboxed solutions allow developers to deploy into production environments safely. The biggest issue that will come up is the limitations on the SharePoint API the developer has when running in a Sandbox solution. In the Sandbox section there is a listing of what can and cannot be done in a Sandbox solution. At a very very highly level you have the ability to create web parts that can work with lists within your site collection and pretty much do anything you need within that scope. Here are the following namespaces that are available to you:

  • Microsoft.SharePoint
  • Microsoft.SharePoint.Administration
  • Microsoft.SharePoint.Navigation
  • Microsoft.SharePoint.UserCode
  • Microsoft.SharePoint.Utilities
  • Microsoft.SharePoint.WebControls
  • Microsoft.SharePoint.WebPartPages
  • Microsoft.SharePoint.Workflow

I can say that many of the departmental level custom solutions I have written would adhere to this. Only place where this would not work well is if:

  • I were creating some sort of Farm Level solution that had to be used everywhere.
  • If you have to go outside of the SharePoint context (i.e. to an external database) you will not be able to call anything that has reference to the SQL API. However you can use the BDC object model to access external data.
  • If you need to run with SPSecurity.RunWithElevatedPrivileges.

There is a great discussion of how Sandboxed Solution DLLs are loaded. Specifically it discusses both the new SharePoint User Code Service and Sandbox Worker Process and how they work together to create new processes where Sandboxed solutions run within. There are maximum levels that will be managed so if too many Sandbox solutions are running, ones that are not being used will be unloaded.

Part 3 - Data Models in SharePoint 2010

Everything in this section is good read. They really help you with the decision process of what type of data you have and how it should be stored and how should the data be accessed based on the nature and life-cycle of that data. You should never make a long term decision of how data will be stored because it is “easy” to do it one way versus another. A real decision needs to be made on the long term management of that data.

There are so many new features in the area of ECM for developers in SharePoint 2010. You have Business Connectivity Services, LINQ to SharePoint, relational lists,

Part 4 - Client Application Models in SharePoint 2010

This section is a whole discussion on client based access to SharePoint 2010; specifically focusing on Rich Internet Applications (RIA) like Silverlight, Ajax, ECMA Javascript, Client Side Object Model, REST Services, etc. You really need to have an understanding of all the tools in the toolbox before you make a commitment on how you are going to build your custom solution because Microsoft has pretty much provided you a tool to solve any use case that can be thrown at you.

I personally liked the “RIA Technologies: Benefits, Tradeoffs, and Considerations” because there were several things in that discussion which I take for granted. I also really liked reading the article “Using the Client Object Model” because it broke down the three main client scripting languages and focused in on the new client-side object model (CSOM).

No comments: