Physical Objects Hierarchy of Microsoft SharePoint Foundation

Last modified: March 13, 2010

Applies to: SharePoint Foundation 2010

The Microsoft SharePoint Foundation object model can be usefully divided into three hierarchies. This topic discusses the Physical Objects Hierarchy, which includes classes that represent physical entities, such as servers and files, and containers of such entities, such as farms and folders.

Important note Important

For a discussion of the entities that are represented by the classes in the hierarchy, see Background: Physical Objects in Microsoft SharePoint Foundation.

The Content Hierarchy; which includes classes that represent publishable items of data, such as list items, and classes that represent nested containers of data, such as lists, content databases, Web sites, collections of Web sites, and groupings of site collections called Web applications; is discussed in Content Hierarchy of SharePoint Foundation.

The third hierarchy, the Services Hierarchy, includes classes that represent services and instances of services. This hierarchy is discussed in Services Hierarchy of Microsoft SharePoint Foundation.

Note Note

These hierarchies overlap in the sense that some classes cannot be easily categorized and can be regarded as belonging to more than one hierarchy.

The classes in the Physical Objects hierarchy represent entities that are either actual physical objects or objects that, depending on the context, can be regarded either as physical objects or as non-physical. The four major classes in the hierarchy are shown in Figure 1.

Figure 1. The Physical Objects hierarchy

Physical Objects hierarchy

The SPFolder and SPFile classes are not discussed in this article; but to avoid misunderstanding, notice that the entity represented by an SPFolder object or an SPFile object might be located in a SharePoint Foundation content database instead of in the file system of a server. For example, a spreadsheet file in a SharePoint Foundation document library is stored in a cell of a database, not in a folder on one of the servers.


A SharePoint Foundation farm is represented by the SPFarm class. A server farm is a cluster of physical servers that includes one or more front-end servers, zero or more application servers, and an SQL Server that may be hosted on a dedicated database server or on one of the application servers (or on a front-end server if there is only one of those). (Strictly speaking, a SharePoint Foundation deployment is always hosted on a farm, although it may be a "farm" with just a single computer that contains the whole deployment.)

These are some of the characteristics of the SPFarm class:

  • The SPFarm class represents a farm of one or more physical servers, so it is included in the Physical Hierarchy. But it can also be considered the top level of the Content Hierarchy; for example, all the (non-configuration) content of a SharePoint Foundation farm can be backed up and restored.

    Note Note

    In SharePoint Foundation the configuration database of a farm cannot be restored. It can be backed up and this may be useful as a snapshot of the database that can be compared with the current state of the database for troubleshooting purposes.

  • In SharePoint Foundation, the SPFarm class can also be thought of as representing the configuration database that is associated with the farm because SharePoint Foundation has no class that represents the configuration database itself. For example, the DisplayName() property of an SPFarm object is also the name of the configuration database.

  • An SPFarm object has three major types of child classes: SPServer, SPService, and SPSolution.

  • SPFarm inherits from SPPersistedObject, which means that the object (there is only one) that instantiates the class persists in the configuration database.

  • SPFarm has static members for creating farms and returning references to the local farm or a remote farm.

  • SPFarm has many members that can be used for developing administration functionality. Some of the more important members can help in the administration of the following:

    • Backup and restoration of the farm

    • Upgrades of the farm

    • Migration of (moving) the farm

    • Error reporting

    • Caching


A physical server in a SharePoint Foundation farm is represented by the SPServer class. In addition to many inherited members, it has an Address property that holds the IP address of the server and a Role property that identifies the server's role in the farm. If there is just one server, its role is SingleServer. If there is more than one, the front-end servers have the role WebFrontEnd and almost all other servers have the role Application. However, the Role property of a server that is physically hosting a SharePoint Foundation content database typically has the value Invalid. This is because such servers typically run only one SharePoint Foundation service—the Database Service (which is a Windows service)—and this database service is really just an alias for the SQL Server Windows service which is not part of SharePoint Foundation. Hence, it is not really running any SharePoint Foundation code, and it does not really fit into the Application role. For more about applications, roles, and services, see Services Hierarchy of Microsoft SharePoint Foundation and Background: Service Entities in Microsoft SharePoint Foundation.

The SPServer class also has a ServerInstances() property that holds references to all the instances of Windows services and Web services that are running on the server. For more information about service instances, see Services Hierarchy of Microsoft SharePoint Foundation and Background: Service Entities in Microsoft SharePoint Foundation.

SPServer inherits from SPPersistedObject. Objects that instantiate SPPersistedObject persist in the SharePoint Foundation configuration database.

See Background: Service Entities in Microsoft SharePoint Foundation for graphic showing a typical farm and its servers.