Best Coding Practices in Share Point Object Model

When developers code in SOM they always faces the  issues related to performance, extensibility, and scalability. Usually all these issue are trouble shoot and tried to resolve by doing some alternate options and developers skips the main reason causing for it.

I am listing some of the key points to use the best coding practice which could avoid the above issues in SOM. I have taken help of MS tech net and MSDN to prepare this article.

Caching Data and Objects

some  of the developers use the Microsoft .NET Framework caching objects to increase overall system performance. But many objects are not "thread safe" and caching those objects can cause applications to fail and unexpected or unrelated user errors

Caching SharePoint Objects That Are Not Thread Safe

Developers use  cache to hold the SPItemCollection for less memory utilization but this object contains the SPWeb opbject which is not thread safe and it leads to execute multiple times in the memory to cause bad performance of the application

Understanding the Potential Pitfalls of Thread Synchronization

Consider the scenario that  you trying to update the list item by Item.update method and you get this happens in 10sec. It works perfectly with you and with 10 more developers.But it start becoming severe when number of users grows try to update the same item with multiple thread at same time. You must it add the lock on the code to happen it in sequence.   

 Coding practice with list and folders

Developers write the code to fetch the list item or update list item in regular development practice. Following are some important points must need to remember while doing the above mentioned operations

Dont fetch the list items using SPList.Items- It selects all items from all sub folders, including all fields in the list. Use the following alternatives for each use case. Use the below given syntax instead of it
SPList.GetItems(SPQuery query)

Paginate the items while fetching it from large lists - When you try to fetch the items from large list always remember to add the row limit  to the items. This will fetch the items with row item size and you will get good performance using this 

Getting items by identifierInstead of using SPList.Items.GetItemById-

SPList.GetItemById(int id, string field1, params string[] fields). Specify the item identifier and the field that you want.

Do not enumerate entire SPList.Items collections or SPFolder.Files collections -
Accessing the methods and properties that are listed in the left column of the following table will enumerate the entire SPList.Items collection, and cause poor performance and throttling for large lists. Instead, use the alternatives listed in the right column.

Table from MSDN

Poor Performing Methods and Properties	Better Performing Alternatives
SPList.Items.Count	SPList.ItemCount
SPList.Items.XmlDataSchema	Create an SPQuery object to retrieve only the items you want.
SPList.Items.NumberOfFields	Create an SPQuery object (specifying the ViewFields) to retrieve only the items you want.
SPList.Items[System.Guid]	SPList.GetItemByUniqueId(System.Guid)
SPList.Items[System.Int32]	SPList.GetItemById(System.Int32)
SPList.Items.GetItemById(System.Int32)	SPList.GetItemById(System.Int32)
SPList.Items.ReorderItems(System.Boolean[],System.Int32[],System.Int32)	Perform a paged query by using SPQuery and reorder the items within each page.
SPFolder.Files.Count	SPFolder.ItemCount

 Deleting Multiple Versions of a List Item

When you delete multiple versions of a list item, use the DeleteByID method; do not use the Delete method. You will experience performance problems if you delete each SPListItemVersion object from an SPListItemVersionCollection object. The recommended practice is to create an array that contains the ID properties of each version and then delete each version by using the SPFileVersionCollection.DeleteByID method.

 

Using SPQuery Objects

SPQuery objects can cause performance problems whenever they return large result sets. The following suggestions will help you optimize your code so that performance will not suffer greatly whenever your searches return large numbers of items.

Do not use an unbounded SPQuery object.An SPQuery object without a value for RowLimit will perform poorly and fail on large lists. Specify a RowLimit between 1 and 2000 and, if necessary, page through the list.

Use indexed fields.

If you query on a field that is not indexed, the query will be blocked whenever it would result in a scan of more items than the query threshold (as soon as there are more items in the list than are specified in the query threshold). Set SPQuery.RowLimit to a value that is less than the query threshold.

If you know the URL of your list item and want to query by FileRef, use SPWeb.GetListItem(string strUrl, string field1, params string[] fields) instead.

Following are the important questions  that you can check while developing any artifact in SP using SOM

• Does my code properly dispose of SharePoint objects?
  
• Does my code cache objects properly?
  
• Does my code cache the correct types of objects?
  
• Does my code use thread synchronization when necessary?
  
• Does my code work as efficiently for 1,000 users as it does for 10 users?