SharePoint Server object model

Microsoft SharePoint 2010 offers a highly structured server-side object model that makes it easy to access objects that represent the various aspects of a SharePoint Web site. From higher-level objects, you can drill down through the object hierarchy to obtain the object that contains the members you need to use in your code. These objects are listed below:

  • SPFarm Objects
  • SPServer Objects
  • SPService Objects
  • SPWebApplication Objects
  • SPSite Objects
  • SPWeb Objects
  • SPList Objects

SPFarm Object:

The SPFarm object is the top level  or root object in the hierarchy, which is designed to interact with the configuration data store. It contains global settings for all the servers, services, and solutions that are installed in a server farm.

Its Servers property contains a collection representing all the servers in the environment, and similarly the Services property has a collection representing all the services.

You can get the current top-level server farm object as follows:

SPFarm myFarm = SPContext.Current.Site.WebApplication.Farm;

To get a reference to either the server farm or the current physical server, you can use the following static properties:

Microsoft.SharePoint.Administration.SPFarm.Local or


SPFarm myFarm = SPFarm.Local;

“SPFarm.Local provides the entry point to the current farm”

The term physical object does not necessarily mean that the objects exist separately on disk. SharePoint stores all objects in the content database. You may consider a physical object as something that might exist (such as a server machine) or that can be stored elsewhere (such as a file).

The SPFarm class has three child classes:

  1. SPServer, which represents a single server within the farm;
  2. SPService, which gives access to the farm’s services; and
  3. SPSolution, which is used to deploy something to the farm.

SPFarm is closely related to the configuration database. For instance, the “DisplayName” property of the SPFarm object returns the name of the configuration database. Like many other objects, SPFarm inherits from SPPersistedObject, which means the object’s data is persisted in the configuration database. That’s the reason so many objects have static properties returning useful information without any visible connection to other objects. They simply pull the data from the configuration database.

SPServer Object:

Each physical server computer is represented by an SPServer type.  The  ”ServiceInstances” property provides access to the set of individual service

instances that run on the individual computers, each as an SPService type.

Typical properties of an SPServer object are the IP address (Address property) and the Role property.

Role returns an enumeration of type SPServerRole:

  •  Application: The server runs a web application.
  •  Invalid: The server has not yet registered any role in the configuration database.
  • SingleServer: The server is the only server in the farm (also called single-server installation).
  •  WebFrontEnd: The server is a regular front-end server in the farm.

As for SPFarm, the SPServer object has a static property, Local, that represents the local machine:

SPServer myserver = SPServer.Local;

Using the constructor with a server’s address, you can instantiate any server’s object from:

SPServer myserver = new SPServer(“myfarm-dev64″);

SPServer’s ServicesInstances property returns all its services. This includes SharePoint’s Windows and web services.

SPService Object:

Each SPService object represents a logical service or application installed in the server farm. A  service object provides access to farm-wide settings of the load-balanced service that a respective service instance implements. Derived types of the SPService class include, for example, objects for Windows services, such as the timer service, search, Microsoft SQL Server, the database service, and objects for  web services.

All services have the SPService base class. The most confusing thing here is that both Windows services and web services inherit from same base class.

Moreover, the SharePoint-specific services, such as incoming e-mail, are in the same class hierarchy. This is another class that inherits from SPPersistedObject, ensuring persistence in the configuration database. The class provides members

that return the assigned and currently running jobs. Most services process jobs in a queue. A service can have multiple instances. The Instances property returns them, and the SPServiceInstance class defines the objects representing an instance. An instance can be started or stopped.

Several web services support features provided by the API as well. The major difference is that web services can be used remotely. The API access is only possible if the code is executed on the target machine. The internal services that SharePoint provides can be configured in several ways. These services are:

  • Web Application service
  • Administration service
  • Timer service
  • Diagnostics service
  • Central Administration service
  • Search service
  • Outgoing E-mail service
  • Incoming E-mail service
  • User Code service
  • Database service

Front-end servers usually run services such as the Web Application service. Application servers with a dedicated function run the Search service, for instance. Depending on the entire farm configuration, the services spread across the farm. The criteria to let one or another service run on a specific machine depend on the expected performance and physical capabilities of the hardware. If you know that the Search service takes 80 percent of the CPU power, then it would be unwise to locate it on the same machine as the front-end server.

From the class model perspective, the services structure has five specific variants:

  1. Windows services (SPWindowsService)
  2. Web services (SPWebService)
  3. Diagnostic services (SPDiagnosticService)
  4. Outgoing E-mail services (SPOutboundEmailService)
  5. Incoming E-mail services (SPIncomingEmailService)

All these classes inherit from SPService. To investigate the current configuration of all services within the farm, the following code snippet is

helpful. It consists of a small console application:

SPServiceCollection services = SPFarm.Local.Services;

foreach (SPService service in services)


SPRunningJobCollection runningJobs = service.RunningJobs;



Services provide specific functions. The execution can be scheduled by a job. A job can be launched by a timer—either regularly (e.g., every 12 hours) or at a specific time (e.g., Monday at 7:00 p.m.)—or triggered by an event. They execute either on one server or on several servers on the farm, depending on

the purpose of the service.

SPWebApplication Object:

Each SPWebApplication object represents a load-balanced web application based on IIS. The  SPWebApplication object provides access to credentials and other server farm–wide application settings.

The Sites property contains the collection of sites or site collections within the web application, and the ContentDatabases property is a collection of content databases used in the web application. The SPWebApplication class replaces the obsolete SPVirtualServer class, but it can still be helpful to think of an SPWebApplication object as a virtual server—that is, a set of one or more physical servers that appear as a single server to users.

The top-level object, SPWebApplication, represents a whole application. Usually this object is directly related to at least one content database.  SPWebApplication inherits from SPWebService, because an application is treated internally like a service. The ContentDatabases property returns a collection of content database represented by SPContentDatabase objects. Each web application is hosted in IIS; hence, the IisSettings property gives  convenient access to the settings without needing a connection to IIS. Similarly, the ApplicationPool property gives access to the application pool.

SPWebApplication is another object that inherits from SPPersistedObject, meaning that the object’s data is persisted in the configuration database.

You can get an SPWebApplication object by different methods. Within a SharePoint application, you can use the current context:

SPWebApplication web = SPContext.Current.Site.WebApplication;

From anywhere else, such as a console application, use the following:

SPWebApplication web = new SPSite(“http://myserver/site”).WebApplication;

You’ve already learned that any request is handled by an ASP.NET application and represented by an HttpApplication object. SharePoint has its own  implementation, SPHttpApplication, which is tightly coupled toSPWebApplication. Each web application runs its own SPHttpApplicationobject. The content stored with the features provided by a web application is held within one or more content databases. Each database object has, along with the web application object, references to one or more SPSite objects.

SPSite Object:

An SPSite object represents the collection of site collections within the web application. The Item property or indexer gets a specified site collection from the collection, and the Add method creates a site collection within the collection.

Each SPSite object, despite its singular name, represents a set of logically relatedSPWeb objects. Such a set is commonly called a site collection, but SPSite is not a typical collection class, like SPWebCollection. Instead, it has members that can be used to manage the site collection. The AllWebs

property provides access to the SPWebCollection object that represents the collection of all web sites within the site collection, including the top-level site. The Microsoft.SharePoint.SPSite.OpenWeb method of the SPSite class returns a specific web site.

If your application does not run inside the context of a SharePoint site, you have to retrieve the Site object based on its URL:

SPSite mySiteCollection = new SPSite(“AbsoluteURL”);

SPWeb Object:

Each site collection includes any number of SPWeb objects, and each object has members that can be used to manage a site, including its template and theme, as well as to access files and folders on the site. The Webs property returns anSPWebCollection object that represents all the subsites of a specified site,

and the Lists property returns an SPListCollection object that represents all the lists in the site.

To return the top-level web site of the current site collection, use the RootWeb property:

SPWeb topSite = SPContext.Current.Site.RootWeb;

The SPContext class does not limit you to getting the current object of any given type. You can use the Microsoft.SharePoint.SPSite.AllWebs property to obtain a reference to any other web site than the current one. The following code returns the context of a specified site by using an indexer with the  AllWebs property:

SPWeb webSite = SPContext.Current.Site.AllWebs[“myOtherSite”];

SPList Object:

Each SPList object has members that are used to manage the list or access items in the list. The GetItems method can be used to perform queries and retrieve items from the list. The Fields property of an SPList returns anSPFieldCollection object that represents all the fields, or columns, in the list, and the Items property returns an SPListItemCollection object that represents all the items, or rows, in the list.

Hope this helps…Happy Coding!!!!

(Visited 22 times, 1 visits today)