SharePoint Object Model‏

Best Practices: Common Coding Issues When Using the SharePoint Object Model

Overview
Developers who write custom code with the SharePoint object model will encounter common issues related to performance, extensibility, and scalability. This article is a resource for developers who are working to troubleshoot and improve the performance of existing SharePoint applications or who are writing new SharePoint applications. In both cases, it is important to understand how to make the SharePoint object model work efficiently, and how to apply general programming techniques (such as caching and threading) to the SharePoint platform specifically. This information can make it easier to design your applications correctly, find and fix problem areas in your code, and avoid known pitfalls of using the SharePoint object model.

The following areas reflect the most common general concerns encountered by SharePoint developers:

Using SharePoint data and objects efficiently
Performance concerns related to folders, lists, and SPQuery objects
Writing applications that scale to large numbers of users
Using Web controls and timer jobs
Disposing of SharePoint objects
This article addresses all but the last of these issues. For guidance on disposing of SharePoint objects, see Best Practices: Using Disposable Windows SharePoint Services Objects.

Additionally, we recommend that you read the following orientation topics as good starting points for using the SharePoint object model:

Server and Site Architecture: Object Model Overview
Understanding the Administrative Object Model of Windows SharePoint Services 3.0

Ref: http://msdn.microsoft.com/en-us/library/bb687949.aspx#WSS3CodingSharePointOM_OverviewofCommonCodingIssueswiththeSharePoin
---------------------------------

Namespaces in the Windows SharePoint Services Object Model

The Windows SharePoint Services object model consists of forty-two namespaces in ten assemblies that are used in SharePoint sites on the server that is running Windows SharePoint Services.

Ref: http://msdn.microsoft.com/en-us/library/ms453225.aspx

----------------------------------

Windows SharePoint Services 3.0: Software Development Kit (SDK)

Brief Description
The Windows SharePoint Services 3.0 software development kit (SDK) contains conceptual overviews, programming tasks, samples, and references to guide you in developing solutions based on Windows SharePoint Services 3.0.

Overview
The Windows SharePoint Services 3.0 SDK contains conceptual overviews, programming tasks, and references to guide you in developing solutions based on Windows SharePoint Services as a platform. The SDK includes information about the following technologies:

Web Part Framework Create, package, and deploy Web Parts on SharePoint sites.
Server-side object model Work with individual lists and sites or manage an entire Windows SharePoint Services deployment.
Web services Use default Web services, or create custom Web services, to interact with Windows SharePoint Services from external applications.
Collaborative Application Markup Language (CAML) Customize the schemas that define lists and sites, define queries for use with members of the object model or Web services, and specify parameters for use with methods in Remote Procedure Call (RPC) protocol.
Master Pages Specify all of the shared elements of your site in the master page or pages, and add content page-specific elements to content pages.
Workflows Create workflows that encapsulate business processes to be performed on items in Windows SharePoint Services, and attach those workflows to items in Windows SharePoint Services.
Custom Field Types Create custom field types that conform to your business data. These custom field types can be based on the base field types already included in Windows SharePoint Services, and can include custom data validation, field rendering, and field property rendering and processing.
Information Rights Management (IRM) Specify IRM for files located in document libraries and stored as attachments to list items. Create IRM protectors for your own custom file types.
Document Property Promotion and Demotion Use the built-in XML parser to synchronize the document properties and list column data for XML documents. Create document parsers to do the same for your custom file types.
Search Use the new Query object model and Query Web service to retrieve search results. Search in Windows SharePoint Services now shares the same SharePoint search technology used by Microsoft Office SharePoint Server 2007.

Ref: http://www.microsoft.com/downloads/details.aspx?FamilyId=05E0DD12-8394-402B-8936-A07FE8AFAFFD&displaylang=en

----------------------------------

Best Practices: SharePoint Object Model for Performance Tuning

While working with SharePoint object model, most of developers will use SPWeb, SPSite, SPList objects intensively.

I had worked with some customers who reported performance issues in their production environment after their project deployment. Their code works well in most of the scenarios but whenever the data get increases then there might be potential performance hits because of not handling the APIs properly.

In this post I will give information about some common methods that we are using in most of the scenarios and very important points that we need to remember in perspective of application’s performance. We do have two cool MSDN articles gives information about the best practices with SharePoint object model and I will recommend you all to go through those articles as well. Also we do have an excellent blog by Roget Lamb by giving the detailed information of Dispose Patterns with examples.

Best Practices: Common Coding Issues When Using the SharePoint Object Model

Best Practices: Using Disposable Windows SharePoint Services Objects

Roger Lamb’s cool post about SharePoint 2007 and WSS 3.0 Dispose Patterns by Example

Lots of situations where we will use APIs for retrieving information about Lists and List Items. In SharePoint, lists are the objects storing large amount of data. So we need to be little cautious while working with those APIs, because internally those APIs are calling some SQL queries to pull the data which has been stored the SharePoint Content DBs.

The performance issues may happen in some cases if numbers of lists are very high or in some cases total number of lists will be less but the items will be very large.

Ref: http://blogs.msdn.com/sowmyancs/archive/2008/10/26/best-practices-sharepoint-object-model-for-performance-tuning.aspx
----------------------------------