Basics: Interact with SharePoint 2010 Data (post 2 – Server Object Model)

In a previous post, I made an introduction to interacting with SharePoint data through Web Services; easily, albeit a bit on the verbose side.

In 2007, the way to go was by leveraging the Server Object Model (SOM). This is of course kept in the 2010 version of the platform. Today, I’m going to make a short introduction to how you’re able to communicate with your objects on a SharePoint site collection.

First of all, we need to make clear that, in order to use Visual Studio for our SharePoint programming, we will first need to define a connection and context. We did see how that was done in the previous post, when we we used the Lists.asmx web service in order to gain access to the site collection’s lists.

This time, we will leverage the SOM, Server Object Model. Just as programmers used to when they worked with the previous version of SharePoint.

In order to get our application to speak with SharePoint, we need to add a reference to the Microsoft.Sharepoint.dll library. In order to do that, we will need to right click on our project, select “Add reference” and then pick up the Microsoft.Sharepoint.dll library from the .NET list of references. As always, do make sure that you’re leveraging the 3.5 version of the .NET framework. You will need to do that by hand, unless you’ve chosen a SharePoint 2010 type of project (in which case, the appropriate dll will have already been referenced by the IDE).

Having added the reference, you will need to add a “using” statement in your application’s list of “using” statements. Note that, you will have to use the “using” statement even if you’ve selected a SharePoint 2010 type of project and the reference has already been automatically added for you.

Once you have made the above couple of steps, you can easily try the following code. In order to keep this simple, try creating a web part. It’s the same logic behind WPF applications but you will then need to provide authentication credentials.

//don’t forget to add: using Microsoft.Sharepoint;
//create a button (btnList) and a listbox (lstboxLists). We will populate the listbox with the names of all the lists that appear in our site collection.
//define a string variable to store your site collection URL (call it scURL) and another one to store the individual lists’ names (call it listName)
//put the following code into your button_Click event

using (SPSite mySiteCollection = new SPSite(scURL)) //don’t forget you need to have already set the scURL to your absolute URL. This here defines the site collection you will be working with
{
using (SPWeb mySite = mySiteCollection.RootWeb) //this here defines the web site you will be working with
{
foreach (SPList myList in mySite.Lists) //this here iterates the items that are present in the Lists collection of your web site
{
listName=myList.Title.ToString(); //you convert the lists’ titles into string type and save them in the local field listName.
lstboxLists.Items.Add(listName); //you add the name of the list to the listbox collection.
}
}
}

That’s just how easy it was to leverage the Server Object Model to interact with elements in your SharePoint infrastructure. In the next post, we will see how to use the new Client Object Model in order to interact with SharePoint.

The important thing to remember here is that although there’s a number of tools available to to the programmer, each is better suited to some task. When there’s only server activity associated with a task, it is better to leverage the Server Object Model. You should be using the Client Object Model (COM) when dealing with remote client applications.