关于Sharepoint的服务器端对象模型的内容很庞大很繁杂，而事实上，我们在这里只把最关键的对象梳理一下，我们会从三个体系来大致描述它们。
这三个体系分别是：
1、物理对象层次结构(Physical Objects Hierarchy)
2、内容层次结构(Content Hierarchy)
3、服务层次结构(Services Hierarchy)。
希望通过我们的大致描述能让你对Sharepoint的服务器端对象模型能有一个大致的了解。下面进入主题。
这里先看看物理对象层次结构(Physical Objects Hierarchy)
物理对象层次结构中的类所表示的实体既可以是实际物理对象(SPFarm, SPServer)，也可以是根据上下文(Context)被视为物理对象或非物理对象的对象(SPFolder,SPFile)。
下图显示了该层次结构中的四个主要类。
它们中最重要的两个类就是Servers与Farms。
Sharepoint Fundation Farm以及它的配置数据库(configuration database)就是由SFarm类来表示的。
Sharepoint的服务器场(Farm)是一个物理服务器集群，包括一个或多个前端服务器(Front-End Web Server)，零个或更多的应用服务器(Application Server)以及SQL服务器，SQL服务器可能被寄存在专用的数据库服务器(dedicated database Server，虽然在这种专用数据库服务器上并不安装Sharepoint，但它们仍是Sharepoint场的组成成员，我们可以在Sharepoint场的管理中心界面上看到它们)上或者在其中一个应用服务器上(如:在一台前端服务器上)。 (严格的讲，Windows SharePoint Services 3.0总是部署在场中，虽然有可能它是整个部署环境(场)中唯一的一台计算机。
SharePoint Foundation 场中的物理服务器具有 IP 地址和角色。以下是 SharePoint Foundation 中的服务器可能具有的三种(或四种)角色：
1、单一服务器(Single Server)：从名称的含义可以得知，当且仅当服务器是场中的唯一服务器时，服务器将具有此角色。
2、前端服务器(Front-End Web Server)：多台服务器都可以具有此角色。前端服务器接受来自客户端计算机的 HTTP 请求。由于前端服务器提供响应这些请求的内容，因此前端服务器上必须运行内容发布 Web 应用程序。
3、应用程序服务器(Application Server)：任何未用作前端服务器或单一服务器的 SharePoint Foundation 服务器都具有应用程序服务器角色（有一种例外情况：见4）。这些服务器运行的是必须从前端服务器卸载的专用 SharePoint Foundation Web 服务或 Windows 服务，这是因为它们需要大量使用服务器的处理器、硬盘或其他硬件资源。SharePoint Foundation 附带了经常卸载到应用程序服务器的一些服务，开发人员可以使用 SharePoint Foundation 对象模型来开发其他服务，并将这些服务作为 SharePoint Foundation 部署的一部分运行。给定的 Web 服务或 Windows 服务可以在多台应用程序服务器上运行。例如，搜索服务可以在多台服务器上运行。每台服务器均具有该服务的单独实例
4、专用数据库服务器（Dedicated Database Server）:上面提到的例外情况是指承载 SQL Server 数据库的服务器。此数据库可以位于任何应用程序服务器上，但通常情况下，如果 SharePoint Foundation 部署的规模大到需要多个服务器场，则此数据库将需要自己的服务器（可能是一个服务器镜像群集）。当此数据库位于它自己的专用服务器（或群集）上时，甚至不会在此服务器上安装 SharePoint Foundation。场的配置数据库中将标识此服务器，并且此服务器会让场以为它正在运行一个称作"Windows SharePoint Services 数据库服务"的服务，而实际上，此服务只是数据库服务器上运行的 SQL Server 服务的别名。此专用服务器上通常不会安装 SharePoint Foundation，并且此专用服务器实际上不具有场中的角色。
关于场的负载平衡问题：
如果Sharepoint场有多台前端Web服务器，那么它们通常都需要负载平衡的(load-balance) 支持。你可以使用硬件支持或软件支持的负载平衡解决方案(包括Windows Server2008内置的网络负载平衡(NLB:Network Load Balancing)方案)。你需要清楚的是：Sharepoint自身并不支持负载平衡解决方案。
当使用了负载平衡方案后，系统将会把客户端计算机的传入网络连接指引到场中当时最不繁忙的那一台前端计算机。这样，执行服务的客户端连接的工作负荷将分摊到多台服务器，进而分摊到多个处理器、硬盘驱动器和其他外围设备，从而让客户端获得更好的性能。此外，这样做还有这样一个好处：如果某一台服务器将发生崩溃，则其他服务器还可以继续处理所有传入连接。此时，服务的速度可能会减慢，但服务不会完全停止。
由于场在外部网络中作为单一服务器出现，如果有客户端计算机想要访问场中的某个资源(如: 特定应用程序、文件、数据库或网页)，这个客户端计算机不在乎（通常是不知道）它们将与场中的哪一台物理服务器连接，因此必须对客户端可能会连接到的所有计算机进行相同的配置。
完成相同配置的最简单方法是，在所有计算机上安装相同的应用程序并将任何所需文件、数据库和网页的副本放置在所有计算机上（使用相同的目录路径）。不过，由于此方法要求将客户端对文件、数据库或服务器上保留的任何其他项所做的每个更改传播到所有其他服务器，因此几乎不可行。若要确保服务器保持同步，场必须在传播过程中阻止传入连接。由所有传播导致的性能降低会使场应提供的优势不再存在。实际上，甚至于连适度使用的 SharePoint Foundation 部署也会陷于几乎不停地传播更改的状态。 为了避免这些问题，可以为场中的某些服务器分配特殊任务，如承载数据库。虽然客户端连接到的前端服务器不会将数据库复制到它们上面，但仍需对这些服务器进行相同的配置，这是因为这些服务器将使用相同的连接字符串和网络地址来访问数据库。
关于SPFarm类
SPFarm类继承自SPPersistedObject，它代表一台或多台物理服务器组成的场，因此它被包含在物理层次中。
但是它同样可以被认为是内容层次结构(Content Hierarchy)的最顶级; 例如，所有Windows SharePoint Services 场的(非配置)内容都支持备份和恢复。
在Windows SharePoint Services 3.0中，SPFarm类也可以被视作和服务器场相关的配置数据库的代表，因为Windows SharePoint Services 3.0没有代表配置数据库的类。例如，SPFarm对象的 DisplayName属性也是配置数据库的名字。
SPFarm对象有三个主要的子类型： SPServer、SPService和SPSolution。
SPFarm从SPPersistedObject继承，意味着它的对象(只有一个)实例保存在配置数据库中。
SPFarm的静态成员能够建立服务器场和返回本地或远程的服务器场。
SPFarm类有许多成员可以用来开发管理功能，一些更重要的成员可以用来帮助管理，如下：
- Backup and restoration of the farm(备份和还原服务器场)
- Upgrades of the farm (升级服务器场)
- Migration of (moving) the farm（升级服务器场）
- Error reporting（错误报告）
- Caching （缓存）
下面是 SharePoint Foundation 场(Farm)的一些特征：
- 每个 SharePoint Foundation 场都具有一个配置数据库（configuration database），此数据库包含有关场、场的服务器和场的其他重要子类的信息。
- 场是对象模型的一个级别，可以在此级别安装 SharePoint Foundation 解决方案，也可以从此级别将解决方案部署到服务器和 SharePoint Foundation Web 应用程序(web application)。
- 场是可从中激活 SharePoint Foundation 功能(feature)的四个级别之一。其他三个级别为网站、网站集和 Web 应用程序。
关于SPServer类
SPServer类在Windows SharePoint Services 场中代表一台物理服务器。
除许多被继承的成员之外，SPServer类有个Address属性，这个属性保存了服务器的IP地址。而SPServer类的Role属性用来分辨服务器角色。 如果只有一台服务器，它的Role为SingleServer。
如果有超过一台的服务器，前端服务器的Role为WebFrontEnd，并且几乎其他所有的服务器的Role为Application。
然而，实际上寄存Windows SharePoint Services内容服务器的服务器Role属性值为Invalid。因为，这个服务器只运行一个Windows SharePoint service-数据库服务(一个Windows服务)-这个数据库服务实际上是SQL Server Windows service的别名，该SQL Server Windows service并不是Windows SharePoint service的一部分。 因此，它实际上并不运行任何Windows SharePoint service代码，并且它对应用程序角色并不适用。
SPServer类还有一个ServerInstances 属性，可以返回当前服务器上所有的Windows services和Web services的实例.
SPServer从SPPersistedObject继承，SPPersistedObject的实例都保存在配置数据库中