SharePoint 2010: Best Practices

I highly recommend  the book Designing Solutions for Microsoft SharePoint 2010: Making the right architecture and implementation decisions (Patterns & Practices)  for everyone who is involved in the development process for SharePoint 2010.

Here are some "Best Practices" highlights for SharePoint 2007 developers who heading toward 2010:

Naming convention:

 Used to be in 2007:

   SharePoint used to store its files under the folder 12 - which is called  "hive"

 Best Practices 2010:

  Change you language - call it- "SharePoint root" and the folder has a name "14".

WSP: Gac or inetpub bin ?:

 Used to be in 2007:

2007 used to have 2 options how a developer deliver the solution in a dll:
 - GAC - which is called Full-Trust Execution
 - the bin folder  under inetpub - which is called  Bin/CAS Execution

 Best Practices 2010:

 Bin/CAS model is no longer considered a recommended approach.  The Bin/CAS assembly can be loaded only by the IIS worker process associated with the Web application. Thus means that the  ddl under the bin folder in inetpub is not suitable for the deployment of timer jobs, event receivers, service applications and workflows.
The alternative BIN/CAS model is a Hybrid approach(fusion of Full-Trust and Sandbox Execution)

 The Sandboxed solution:

   Used to be in 2007:

There is no analogy in SharePoint 2007

   Best Practices 2010:

The sandboxed solution  gives the sense of the control for Farm Administrators. The sandboxed solution is deployed on the level of the site collection. The farm administrators can easily monitor the performance and set rules for such solution. If solution appeared harmful - impact from it is localized in the scope of the site collection.
 The farm administrators will love the sandboxed solutions, but for developers it means a new set of challenges - please refer to my post regarding the sandboxed solution constraints - SharePoint 2010: Sandboxed solution restrictions and considerations

What's Hybrid Solution anyway?:

   Used to be in 2007:

There is no analogy in SharePoint 2007
 
   Best Practices 2010:

Hybrid approaches enable you to bypass the CAS policy and the limited permission set of the sandboxed environment. The approach involves the creating  a full-trust solution (GAC dll\farm solution) and a sandboxed solution.
  You can extend the abilities of Sandboxed solution through:
 - full-trust proxy;
 - external content types;
 - custom workflow activities.


Content type: creating programmatically
   
      Used to be in 2007:

 The same approach as if in SharePoint 2010 SPContentType Constructor in WSS 3.0

     Best Practices 2010:

 There are 2 options to create a content type:
   1. CAML
   2. Programmatically
The book Designing Solutions for Microsoft SharePoint 2010: Making the right architecture and implementation decisions (Patterns & Practices) recommends to stick with the programmatically defined content types, because it's likely that the content type will evolve. It's easy to keep track of the changes when the creation initially took place in code rather than in CAML.
Do you want to dig dipper into the SharePoint development life cycle? -read on Best Practices: Sharepoint Application Development Life Cycle

 Projected fields

   Used to be in 2007:


There wasn't a possibility to display additional columns from the tagert list A in the view of the list B if the list B has a lookup field to list A. In the case if the additional columns of list A were needed to display in the list B - developer should use SPSiteDataQuery fo Content Query Web Part.

  Best practices 2010:

A developer can add additional columns from the target list in the destination list  - a secondary lookup field

 

 Cascade and soft delete

Used to be in 2007:

There wasn't an ability to setup relationship between 2 lists, one of them has a lookup field to another.

Best practices 2010:

A SPFieldLookup has RelationshipDeleteBehavior Property .

Cascade delete behavior is designed to prevent orphans from occurring.

Restrict or soft delete behavior allows to support consistency. 

The example of it: There are 2 lists: "Products" and "Orders". "Orders" list has a lookup field with restrict delete behavior to the target list "Products". The product is not available anymore. By making a product record inactive we assure that we preserve historical records in the "Orders" list and at the same the creation of new order with inactive product is prohibited.

What is Query Throttling?

Used to be in 2007:

There is no analogy in 2007

Best practices 2010:

 Query Throttling allows farm administrators to mitigate the performance issue associated with large lists by restricting the number of items that can be accessed when you execute a query.

By default, this limit is set to 5000 items for regular users and 20000 items for users in an administrative role.

 The best practice is keep the query throttling on. If you really need to suspend the throttling - go ahead and do it, but be mindful that it should a temporary measure or as a last resort.

BCS or BDC? 

Used to be in 2007:

BDC in 2007 facilitates the SQL connection and WCF services. The data fetched to BDC is read only mode.

Best practices 2010:

For deep insight into BDC and BCS please refer to SharePoint 2010: BCS and BDC

One of the best practices :

Working with complex external content type, please keep in mind in case the data is modeled as read only that SQL data view is less expensive operations than complex modeling of the external content type.

Note: Here is a nice article on MSDN  on migration BDC adf files on SharePoint 2010

Prefer Secure Store Service mapping over RevertToSelf authentication. 

  RevertToSelf uses the credentials of the process running the application to authenticate to the Web service or the database. It poses a potential security risk and is not permitted in hosting environments.

  The Secure Store Service (SSS) is a BCS component.  The SSS maps SharePoint user identities to other external credentials and supports claims-based approaches to authentication.

LINQ vs CAML

 Used to be in 2007:

Before the advent of  LINQ to SharePoint, the SPQuery and SPSiteDataQuery classes where the predominant approaches to performing data operations on SharePoint lists.

Best practices 2010:

Here is a comrehensive article how to use LINQ to SharePoint - Using LINQ to SharePoint .

Even though LINQ seems a good deal for developers,  there are still many scenarios in which SPQuery and SPSiteDataQuery with using CAML provide the most effective approach - and, in some cases, the only viable approach - to data access.

In SharePoint 2010 the SPQuery has been extended to allow you to specify joins and projected fields.

Consider using  SPQuery over LINQ to SharePoint in case:

- when a lookup column in a list refers to a list in another list in another site within the site collection;

- when performance is paramount.

SPQuery class is the only supported way to query external lists.

Using LINQ to SharePoint incurs some additional overhead, because the LINQ query must be dynamically converted to CAML at run time.

Best practices with working with LINQ to SharePoint:

 1. is to examine the CAML output that is generated by your LINQ queries. 

Here is an example how you can utilize the property DataContext.Log in SharePoint:

Util: Logging Linq 2 SharePoint’s CAML queries the simple way

 2. Use View projection.

A view projection queries a specific set of fields from one or more entities.  Without view projections, LINQ gets generated into CAML which selects all fields. With projection only fields that are used in the view projects will get selected.

A rule of thumb "Where to use CAML or LINQ":

If the time it takes to setup and maintain copies of lists in order to build a representative entity model outweighs the time savings from writing LINQ instead of CAML, consider using SPQuery.

RIA Technologies

Rich Internet Applications typically use asynchronous communication. This results in more responsive applications.

 Used to be in 2007:

   No RIA out of the box.

Best practices 2010:

To get a fast knowledge please take a look at SharePoint 2010: Ajax and Silverlight and others

Consider provide an alternative HTML content within the object tag that host  the Silverlight control, for users who have not installed the Silverlight runtime

Initial load time for Ajax\ Silverlight application is higher that standard server-side control page. To reduce the delay time - consider the following strategies:

- caching;

- delayed\predictive loading;

- "minifying" javascript libraries (Microsoft Ajax Minifier)

To get more sustain knowledge regarding this techniques  refer to RIA Technologies: Benefits, Tradeoffs, and Considerations

If RIA app requires substantial computation on the client, prefer Silverlight over Ajax. The untyped nature of javascript will bring the performance down in this case.

Through using Silverlight\ Ajax application a developer will overcome some of the limitations of the Sandboxed solutions such as:

- call an external service;
- access data across the site collection boundaries;
- reach more advanced capabilities of SharePoint (ex. the user profile service)

The other aspect of RIA application is Data Access:

Prefer client-side object model CSOM or the REST interface over the Sharepoint old ASP.Net Web services.

While using CSOM aim to  group your operations to minimize the number of service calls - aka Batching

The CSOM does not provide a mechanism for querying data across multiple lists that are not associated by a lookup field. To perform such a query - create a list aggregation view on the server.

LINQ to SharePoint is not supported by any of the client-side data access mechanism.Thus a developer doesn't have control over the CAML efficiency which is always generated on the server side. 
However, LINO to Object which is in use by client-side data access mechanism reduces network traffic.

The CSOM provides both a synchronous and an asynchronous model. If you use the .Net managed client API or the Silverligh client API, you can use either approach (but keep in mind that Silverlight will not allow you to block the UI thread - in this case you still need to choose the async method of execution).
The appropriate case to use the synchronous methods is in the command\ PowerShell script program.

If you use the ECMAScript API, you must use the asynchronous approach.

The SharePoint REST interface is based on Open Data protocol.  That's mean it's platform-independent. The SharePoint REST is a great way to access SharePoint list data from platforms on which CSOM is not available.

The SharePoint REST interface does not support explicit list joins. You can use the Expand method to navigate from one entity to a related entity. (Refer to Using the REST Interface)

The Expand method in the REST interface is less efficient than CAML query with a join predicate

Improve the REST query efficiency by using view projections. View projection reduce traffic and improve query efficiency.

Using the REST interface from JavaScript requires some extra work. because you can't generate a service proxy. To use it please refer to Using the REST Interface from JavaScript

While using REST prefer method MERGE over PUT. MERGE updates only the fields that are specified. PUT updates all fields , it the field is not specified - the field will be updated with default values.

Batching reduces chattiness, uses network bandwidth more efficiently , improves the responsiveness.


Is My SharePoint 2010 application is testable?

Used to be in 2007:

To implement automated unit testing in SharePoint 2007 app the team should have spent money on TypeMock Isolator for SharePoint

Best practices 2010:

Now you have a free power tool for Visual Studio 2010 to test the SharePont 2010 application. Pleaser refer to The Moles Framework: SharePoint Unit testing best practices for greater detail.