SharePoint 外接程序与 SharePoint 解决方案对比
了解何时应将 SharePoint 扩展作为 SharePoint 外接程序进行开发，以及何时应将其作为 SharePoint 服务器场解决方案或无代码 沙盒解决方案 进行开发。
本文比较 SharePoint 外接程序、服务器场解决方案 和无代码 沙盒解决方案 (NCSS) 的使用案例。
- 新的 SharePoint 外接程序是可能包含基于云的逻辑和数据、SharePoint 组件、以及客户端脚本但不包含在 SharePoint 服务器上运行的自定义托管代码的自包含扩展。 它们从 Office 商店或组织加载项目录中安装，并且可以安装到本地服务器场或 Microsoft SharePoint Online 上。 有关 SharePoint 外接程序的概述，请参阅 SharePoint 外接程序。
- SharePoint 场解决方案是 SharePoint 组件包，这些组件上传到全场范围库（可从中进行安装）。 它们不能通过 Office 应用商店进行分发，也不能在 SharePoint Online 上安装。 它们可以包含在 SharePoint 场服务器上运行的自定义托管代码。 有关场解决方案的基础知识的详细信息，请参阅 SharePoint 2010 中的解决方案概述和场解决方案。
- NCSS 也是 SharePoint 组件的程序包；但是它们从其可安装的位置上载到网站集库。 它们可以安装到本地服务器场或 SharePoint Online，但不能通过 Office 应用商店分发。 它们可以包含与 SharePoint 外接程序几乎相同的描述性组件，并且与外接程序一样，它们可以包含 JavaScript，但它们不包含在 SharePoint 服务器上运行的自定义托管代码。 外接程序和 NCSS 的部署系统中的差异向 NCSS 提供了一个更好的用于简短方案列表的开发选项。 有关沙盒解决方案的信息，请参阅 SharePoint 2010 中的沙盒解决方案。
重要
虽然开发仅包含声明性标记和 JavaScript 的沙盒解决方案（ (NCSS) 称为无代码沙盒解决方案）仍然可行，但我们已弃用沙盒解决方案中的自定义托管代码。 我们引入了全新的 SharePoint 外接程序模型，以替代需要使用托管代码的方案。 加载项模型分离 SharePoint 核心产品与加载项运行时，这样不仅可以大大提升灵活性，还能方便开发者在所选环境中运行代码。 我们意识到，客户对编码沙盒解决方案有投资，我们将负责逐步淘汰这些解决方案。 在可预见的未来，现有编码沙盒解决方案将继续适用于本地 SharePoint 场。 鉴于在线服务的多变性质，我们将根据客户需求，确定对 SharePoint Online 中编码沙盒解决方案的支持需求。 NCSS 继续受到支持。 今后所有投资将会让全新的 SharePoint 外接程序模型变得更丰富，功能更强大。 因此，建议所有新开发应尽可能使用新外接程序模型。 如果必须开发场解决方案或编码沙盒解决方案，建议设计为可轻松演变为更松散耦合的开发模型。
随时开发加载项
我们能向你提供的最重要指导是，在能够开发 SharePoint 外接程序而非 服务器场解决方案或 NCSS 时这样做。 与经典解决方案相比，SharePoint 外接程序 具有以下好处：
- 为用户提供了最简单的发现、购买和安装过程。
- 为管理员提供了最安全的 SharePoint 扩展。
- 为你提供了基于 Microsoft 在线加载项商店的最简单的营销和销售系统。
- 最大程度地提高了你在开发未来升级时的灵活性。
- 最大程度地提高了你利用现有非 SharePoint 编程技能的能力。
- 采用更平稳且更灵活的方式集成基于云的资源。
- 使你的扩展具有与正在运行该加载项的用户的权限不同的权限。
- 使你能够使用跨平台标准，包括 HTML、REST、OData、JavaScript 和 OAuth。
- 使你能够利用 SharePoint 跨域 JavaScript 库访问 SharePoint 数据。 或者，你可以使用与 OAuth 兼容的由 Microsoft 提供的安全令牌服务或使用数字证书获取对 SharePoint 数据的授权。
为最终用户设计加载项或 NCSS 并为管理员设计场解决方案
SharePoint 外接程序和 NCSS 使用 SharePoint 客户端对象模型或 REST 终结点之一来访问 SharePoint 内容和组件。 这些客户端 API 支持为最终用户设计的 SharePoint 扩展。 在此上下文中， (“最终用户”是网站集管理员、网站所有者和网站成员。) 服务器对象模型具有其他 API，用于启用 SharePoint 管理、配置和安全性的编程扩展。 其中包括管理中心、自定义Windows PowerShell命令、计时器作业和自定义备份的扩展。 有关可开发的管理扩展类型的详细信息，请参阅Windows SharePoint Services管理。 这些管理扩展部署在具有服务器场、Web 应用程序或网站集范围的 SharePoint 功能中。 尽管租户和网站集管理员可以安装加载项和 NCSS，但 SharePointfarm 解决方案也由服务器场管理员安装。
服务器对象模型还具有针对列表、库和网站执行的创建、读取、更新和删除 (CRUD) 操作以及对其他 SharePoint 组件执行的操作的 API。 这意味着，服务器对象模型可用于适用于最终用户的扩展，但出于上一节所述的原因，服务器场解决方案 通常不是此类扩展的最佳选择。 因此，无法将 服务器场解决方案 安装到 Microsoft SharePoint Online 上也就不足为奇。 由于 Microsoft 处理了 SharePoint Online 的所有管理工作，因此无需管理扩展。 有关 SharePoint 中不同 API 集及其重叠位置的详细信息，请参阅 在 SharePoint 中选择正确的 API 集。
客户端对象模型和 REST 终结点不会复制服务器对象模型的面向管理的 API。 此外，由于 SharePoint 外接程序和 NCSS 均不能包含在 SharePoint 服务器上运行的自定义代码，因此它们无法调用这些管理 API。 此外，SharePoint 外接程序中的所有功能都必须具有网站范围;NCSS 中的 和 功能具有网站集或网站范围。 因此，对于 SharePoint 外接程序或 NCSS，实际上无法实现面向管理的 SharePoint 扩展。 因此，第二个原则（但不是绝对规则）是外接程序和 NCSS 适用于最终用户，而服务器场解决方案适用于管理员。
为品牌或类似于模板的扩展设计 NCSS
你可能会遇到少数 SharePoint 开发出现的一种情况，即加载项模型不是最适合的，但你也无法实现 服务器场解决方案，可能是因为解决方案需要安装在 SharePoint Online 上或者需要由网站集管理员安装。 有两种使用广泛且重叠的解决方案。
品牌塑造：SharePoint 用户经常希望使用自己的颜色、样式、布局和徽标，为自己的 SharePoint 网站（包括 SharePoint Online 网站）指定自定义外观。 为此，使用 NCSS 通常比使用 SharePoint 加载项更容易。SharePoint 加载项只能以声明方式控制自己加载项 Web 的外观。 对于主机 Web，它只能以声明方式添加功能区按钮和菜单项（以及加载项部件）。 必须通过使用 SharePoint 客户端对象模型之一的代码或脚本，完成对主机 Web 或其父网站集、租赁或本地 SharePoint Web 应用的其他任何更改。 例如，必须以编程方式部署新图标或 CSS 文件。 此代码可以通过已安装的加载项本身运行，也可以在加载项安装事件处理程序中运行。 不过，创建此代码的工作量非常巨大。 此外，加载项需要网站集范围内的权限，才能在自己的加载项 Web 和主机 Web 外更改任何网站，并且需要租户范围内的权限，才能更改除父网站集以外的其他对象。 不过，可以在任何网站集中部署并激活品牌塑造 NCSS，其中可能只包含一些纯声明性组件。
注意
请注意，对于品牌塑造，虽然 SharePoint 场解决方案可能比 NCSS 或 SharePoint 加载项更为功能强大，但无法在 SharePoint Online 上使用。
"类似于模板"扩展： 假设你需要为商业危机的协作分析和解决方案创建 SharePoint 的危机管理扩展。 你的扩展包括若干自定义列表类型、无代码工作流以及其他 SharePoint 组件，所有这些内容都将组合到一个自定义 WebTemplate 中。 假设你打包扩展并将其部署为 NCSS。 在解决方案中的功能激活之后，用户可在发生危机时创建其 SharePoint 网站的危机管理子网。 他们可以使用特定于危机的数据填充网站。 另一方面，你可以实现与直接使用相同 SharePoint 组件集的 SharePoint 外接程序 相同的扩展。 当在工作组网站上安装了加载项时，将立即创建子网（也称为"加载项 Web"）。 此外，用户可使用相关数据填充网站。
现在，发生第二次危机时出现了什么情况？ 如果你将扩展实现为 NCSS，用户仅可以从自定义 WebTemplate 创建另一个子网。 但是，如果你将扩展实现为 SharePoint 外接程序，你的用户将遇到问题。 他们无法在父网站上安装同一加载项的第二个实例。 在主机 Web 上仅可以安装任何加载项的一个实例。 最佳做法是创建父网站的一个子网站以用作安装加载项的其他实例的位置。 当安装加载项时，将为加载项组件创建新的加载项 Web，它是父网站的一个子网。 这一比较显示一个一般原则（而非绝对原则）：具有"类似于模板"字符的 SharePoint 扩展（即必须为每个特定用户案例配置的可用组件集，但本质上具有与相同的 SharePoint 网站关联的多个实例）与加载项模型相比，更适合 NCSS 部署模型。 在此示例中，可变元素是危机，但是很容易想象类似于模板的 SharePoint 扩展，在该扩展中，实例根据地区、日期或任何数量的其他特性而不同。
有关如何扩展 SharePoint 外接程序的可能性的信息，请参阅 保守地使用外接程序事件处理程序 和 创建扩展的外接程序。
按照加载项的方式执行操作
如前所述，SharePoint 外接程序中不允许在 SharePoint 服务器上运行的自定义代码。 这不是一 个重大限制。 它仅意味着，你的自定义业务逻辑将“向下”移至客户端设备或“向上”移至云。 在任一情况下，都可以使用 SharePoint REST/OData 服务 访问 SharePoint 网站、列表和其他数据。 还可以通过 SharePoint JavaScript、Silverlight 或 .NET Framework 客户端对象模型远程访问 SharePoint 数据。 最后，在 Windows Phone 上，可以通过 SharePointWindows Phone 对象模型访问 SharePoint。 有关 SharePoint 中各种 API 集的详细信息，请参阅 在 SharePoint 中选择正确的 API 集。
对于 SharePoint 外接程序 中的功能无法具有网站集、Web 应用程序或服务器场范围也是同样的道理。 但是，你无需放弃某些用户界面 (UI) 元素或功能。 这意味着组件的实现从 SharePoint 移出，移动到客户端、远程 Web 应用程序或远程数据库。
下表列出了无法在 SharePoint 外接程序 中部署的 SharePoint 组件，并描述了获取相同功能的"加载项方式"。
| 如果你需要以下各项的功能... | ...尝试这些方法。 |
|---|---|
| 自定义 Web 部件 |
SharePoint 外接程序可以具有包含自定义 Web 部件的远程页面。 另一种选择是，在 SharePoint 网站页上的加载项部分中显示远程 Web 应用程序中的页面。 远程页面可以具有与 Web 部件基本相同的 UI 控件和功能。 有关详细信息，请参阅创建与 SharePoint 加载项一起安装的加载项部件。 |
| 事件接收器和功能接收器 | SharePoint 外接程序可包含具有相同功能的远程事件接收器。 有关详细信息，请参阅处理 SharePoint 加载项中的事件。 |
| 自定义字段（列） | 加载项可部署基于某个现有字段类型的新字段（列）。 Calculated 和 Computed 字段类型相当灵活。 另一个选项是使用自定义控件或网格在远程网页中显示数据。 |
| 基于 SharePoint 服务应用程序框架构建的自定义 Web 服务 | 可以将自定义 Web 服务作为远程服务开发。 |
| 应用程序页 | SharePoint 外接程序可以包含可从安装加载项的每个网站获取的远程网页。 加载项还可以使用网站页面上的任何内置 SharePoint Web 部件。 |
下面列出的某些 SharePoint 组件用于最终用户方案，但在 SharePoint 外接程序模型中没有等效项，并且无法在 NCSS 中部署。 对于这些组件，你必须使用 服务器场解决方案。
- 自定义网站定义 但是自定义 WebTemplates（功能类似于网站定义）在 NCSS 和 SharePoint 外接程序 中均可用。有关详细信息，请参阅 使用模板和定义。
- 委派控件 有关详细信息，请参阅 委派控件（控件模板化）。
- 自定义主题
- 自定义操作组和自定义操作隐藏
- 用户控件 (*.ascx 文件) 实际上不需要这些方案。
谨慎使用加载项事件处理程序
通过创建适用于安装的加载项、更新的加载项和加载项卸载事件的处理程序，你可以克服 SharePoint 外接程序的某些限制。 这些处理程序是托管在 SharePoint 场外（可能在云中）的 Web 服务器上的 Web 服务。 它们可以使用 SharePoint 客户端对象模型或 REST API 来在 SharePoint 组件（包括主机 Web 中的组件）上执行 CRUD 操作。 理论上，你可以使用此类处理程序克服之前讨论的 品牌 和 类似于模板扩展 项中的某些部署限制。 但是，当没有其他方法来向客户提供使用案例所需的功能时，我们建议你仅使用此类处理程序作为最后的方法。 当确定是否创建处理程序时，请考虑以下事项：
- 通过编程方式部署到主机 Web 需要加载项请求对主机 Web 的"完全控制"权限。 需要此权限级别的加载项无法通过 Office 商店 出售。
- 到主机 Web 的组件部署会危害将 SharePoint 组件放置在具有其自己的域的加载项 Web 中的安全优势。
- 与可用于加载项 Web 组件和 NCSS 中的描述性部署标记相比，广泛的部署代码将需要大量创建和调试工作。
- 在创建加载项事件处理程序时必须遵循某些重要的最佳做法。 如果你的代码出现错误，则它必须包括回滚逻辑以放弃它已完成的所有操作。 它还必须警告有关 SharePoint 基础结构的错误，以便基础结构可以回滚它已完成的所有操作。
- 加载项事件处理程序无法包含 SharePoint 外接程序（称为托管的 SharePoint）的类型。
有关外接程序事件处理程序的详细信息，请参阅 SDK 节点处理 SharePoint 外接程序中的事件。有关回滚逻辑的信息，请参阅在 SharePoint 外接程序中创建更新事件的处理程序主题的将回滚逻辑添加到处理程序部分。后一个主题是在外接程序更新事件的上下文中编写的，但基本原则适用于所有外接程序事件处理程序。
用于创建扩展的加载项
使用 SharePoint 客户端对象模型或其 REST API 来解决 SharePoint 外接程序的组件部署问题的另一种方法是，使 CRUD 代码位于加载项本身中，而不是位于加载项事件处理程序中。 然后该加载项将成为适用于自定义扩展类型的一种工厂。 例如，SharePoint 托管的加载项可以使用 SharePointJavaScript 对象模型在主机 Web 或者租户或 Web 应用程序中的任意位置上执行部署和其他 CRUD 操作。 有关其他示例，请参阅 SharePoint 中网站设置技术和远程设置 的 远程设置快速简介 ，它介绍了如何使用提供商托管的 SharePoint 外接程序 在内置子网设置中提供子网设置（与 SharePoint 的设置非常相似）。 但是，存在大量需重新创造的方面，因此创建工厂 SharePoint 外接程序 需要投入大量工作。 此外，此类加载项无法通过 Office 商店出售，因为该加载项需要主机 Web 的"完全控制"。