选择 SharePoint 加载项设计选项时的三种考虑方式
先决条件：应先熟悉 SharePoint 加载项一文。
本文介绍了选择 SharePoint 加载项体系结构选项时的三种考虑方式。 首先，了解最重要类别的设计选项有哪些；其次，从应用层角度出发审视加载项体系结构；再者，了解在选择设计选项时需要考虑的一系列因素。
要做出的第一个决定是，SharePoint 扩展应该是 SharePoint 加载项，还是经典 SharePoint 场解决方案或沙盒解决方案。 SharePoint 对象模型的一些部分（主要是与自定义 SharePoint 管理和安全性相关）无法从客户端访问。 只有在 SharePoint 服务器上运行的自定义代码才能访问它们，而 SharePoint 加载项中禁止使用自定义服务器端代码。 （借助大量客户端对象模型和 REST/OData 服务，SharePoint 加载项可以执行几乎所有面向最终用户的 SharePoint 扩展。）
若要详细了解如何确定使用经典解决方案还是使用加载项，请参阅 SharePoint 加载项与 SharePoint 解决方案对比 在 SharePoint 中选择正确的 API 集一文也有助于做出此决定。
SharePoint 加载项的关键设计元素
设计 SharePoint 加载项时，需要选择三大类的设计选项。 一如既往，应用设计需要有所取舍；选择的一类选项可能会限制另一类选项。 并不是每种可能的选项组合都可行。
托管：根据部署和托管方式，SharePoint 加载项可分为两大类：
提供程序托管加载项的主要数据存储和业务逻辑由开发人员部署和托管在 SharePoint 外的服务器中，或由开发人员提供的云帐户进行部署和托管。 开发人员负责强制隔离购买加载项的各个客户的帐户。 此类加载项也可以有 SharePoint 组件。 它们托管在客户的 SharePoint 场中。 使用此类加载项，可以最灵活地选择其他类别的设计选项。 此外，还可以对外部数据、逻辑和 Web 用户界面 (UI) 使用非 Microsoft 平台。 (在提供程序托管的外接程序类别中，还需要区分其远程组件与 SharePoint 场位于同一企业防火墙中的外接程序和远程组件位于该防火墙之外的外接程序。这两种方案的授权系统是不同的，这反过来又会改变你用来访问 SharePoint 数据的编程语言。)
SharePoint 托管的 外接程序完全由 SharePoint 组件组成，例如列表、内容类型、工作流和 Web 部件。 没有外部组件。 有关 SharePoint 外接程序中可包含的 SharePoint 组件类型的详细信息，请参阅 SharePoint 中的托管 Web、外接程序 Web 和 SharePoint 组件。
若要详细了解 SharePoint 加载项托管选项，请参阅选择用于开发和托管 SharePoint 加载项的模式。
连接：SharePoint 支持对数据执行三种安全的创建/读取/更新/删除 (CRUD) 操作。
加载项中的外部 Web 应用使用 OAuth 协议访问 SharePoint 数据。 有关详细信息，请参阅 SharePoint 加载项的授权和身份验证。
JavaScript 可使用支持安全跨域脚本的特殊 JavaScript 库，访问 SharePoint 加载项 Web 中的数据和相同租赁中其他网站上的数据。 有关详细信息，请参阅使用跨域库从加载项访问 SharePoint 数据。
SharePoint 加载项还可以通过 Business Connectivity Services (BCS) 或 Web 服务代理访问外部数据。 有关详细信息，请参阅 SharePoint 中的 Business Connectivity Services 和在 SharePoint 中使用 Web 代理查询远程服务。
若要详细了解 SharePoint 加载项中的数据存储和数据访问，请参阅 SharePoint 加载项中的数据存储、SharePoint 加载项的安全数据访问和客户端对象模型和在 SharePoint 中处理外部数据。
Ui： 有三种方法可以在 SharePoint 中显示 SharePoint 外接程序：至少，所有加载项都显示在完整的网页中。 或者，也可以通过外接程序部件显示外接程序，以及通过菜单项或功能区按钮显示外接程序。 有关详细信息，请参阅 SharePoint 外接程序的 UX 设计。
注意
客户可以将 SharePoint 加载项安装到租赁中的多个网站集，也可以安装到各个网站。 前者称为“租户范围加载项”。如果希望客户可以使用租户范围选项，不得添加自定义功能区按钮或加载项部件。 有关详细信息，请参阅 SharePoint 加载项的租赁和部署范围。
体系结构层
考虑外接程序体系结构选项的另一个方法是将外接程序视为具有三个逻辑层：UI、业务逻辑和数据访问。 每一层都有多个实现选项；再次重申，对某一层做出的选择将限制对其他层的选择。 下表介绍了外接程序的远程组件和 SharePoint 组件的一部分选项及其用途。
提供程序托管的外接程序的远程组件：每一层的选项
| 层 | 选项 | 适用于 |
|---|---|---|
| UI | 以 Azure Web 角色托管的 ASP.NET 表单或 MVC 应用中的 ASP.NET 页 | 充分发挥 ASP.NET 开发人员的技能水平 |
| 使用 JavaScript 的 HTML 5 页面 | 丰富用户界面 | |
| PHP 或非 Microsoft 云服务中托管的其他类型网页 | 将非 Microsoft 应用集成到 SharePoint 中 | |
| Windows Phone 应用中的 Silverlight | 移动访问 SharePoint 数据，并集成地理位置数据和推送通知 | |
| 业务逻辑 | 客户端 JavaScript | UI 逻辑和轻量级业务逻辑；通过 JavaScript 客户端对象模型访问 SharePoint 数据 |
| Microsoft Azure 辅助角色 | 占用大量处理器资源的功能；通过 .NET Framework 客户端对象模型访问 SharePoint 数据 | |
| 远程 Web 服务 | 占用大量处理器资源的功能；通过 .NET Framework 客户端对象模型访问 SharePoint 数据 | |
| 数据 | SQL Azure | 功能齐全的关系数据 |
| Azure 表存储 | 应用设置和其他元数据 | |
| Azure Blob 存储 | 存储大型文件 | |
| 非 Microsoft 云服务 | 利用基于非 Microsoft 平台的现有数据源 | |
| 开发人员自己的服务器上的数据库 | 提供程序托管和开发人员控制的租赁隔离 |
SharePoint 组件：每层可用的选项
| 层 | 选项 | 适用于 |
|---|---|---|
| UI | 加载项网页上的 SharePoint 列表和库的自定义视图 | 最大限度地与 SharePoint 外观和行为集成 |
| 托管在 Web 部件中的 Silverlight 应用程序 (或 <外接程序网页上的对象> 标记) | 利用现有 Silverlight 开发经验；丰富用户界面 | |
| 业务逻辑 | SharePoint 工作流 | 实现业务流程 |
| 使用 SharePoint 跨域库作为补充的客户端 JavaScript | 访问加载项 Web 中的 SharePoint 数据；访问租赁内其他网站中的数据 | |
| 远程事件处理程序 | 使用外部托管的逻辑处理 SharePoint 列表和库中的 CRUD 事件 | |
| 数据 | 通过协作应用标记语言 (CAML) 或 LINQ 查询以及 SharePoint 客户端对象模型之一查询到的 SharePoint 列表和库 | 利用现有 SharePoint 和 .NET Framework 开发经验 |
| 通过 SharePoint REST/OData Web 服务查询的 SharePoint 列表和库 | 访问非 Microsoft 平台中的 SharePoint 数据；利用现有 OData 查询体验 | |
| BCS 模型 | 在 SharePoint 中以 SharePoint 列表形式显示外部数据 |
做出设计决策时要考虑的因素
SharePoint 外接程序模型使单个决策树无法实现的很多功能都成为了现实。 下面是在构造 SharePoint 外接程序的体系结构时要考虑的一些最重要的因素。
最重要的当然是要为客户提供的功能，即用例。 例如，如果加载项包括占用大量处理器资源的功能（如将视频文件转换为其他视频格式），这就表示有必要创建提供程序托管加载项，即处理工作是在服务器之一或 Azure 辅助角色上完成。
由于提供程序托管的外接程序（一种 SharePoint 外接程序）要求您（或您的客户）托管非 SharePoint 组件并强制实现租户隔离，因此您需要考虑是否让硬件和 IT 员工执行此操作（或是否让您的目标客户执行此操作）。
您的目标客户是哪些也是一个重要的考虑事项。 如果您的所有外接程序都是在内部使用的（也就是说，您没有外部客户），那么提供程序托管的外接程序的实现和维护将比您有外部客户时容易得多。 如果您打算公开出售外接程序，则还应考虑是将外接程序销售给具有 SharePoint Online 帐户的企业，销售给具有其自己的 SharePoint 场的企业，还是具有这两者的企业。
您还应考虑您的现有技能或您的开发员工的技能。 例如，如果您是一个有经验的 ASP.NET 开发人员，则可以考虑创建远程 Web 应用程序以及在 ASP.NET 页上显示 Sharepoint 列表数据。 另一方面，如果您是一个有经验的 SharePoint 开发人员，则可以考虑将自定义 SharePoint 列表和网站页与 JavaScript 结合使用来执行处理。