将 SharePoint 开发与其他形式的开发进行比较

甜思思

　　从三个视点检查 SharePoint 开发很有用：  

• 为 .NET Framework 构建可扩展的应用程序
  
• 构建数据库应用程序
  
• 构建传统的富客户端应用程序
  

将 SharePoint 应用程序与可扩展的 .NET Web 应用程序进行比较

　　您可以从开发人员的角度检查 SharePoint 开发，该开发人员构建了在大型服务器场上运行的高度可扩展的松散耦合 Web 应用程序。这些应用程序每分钟必须处理数百个或数千个页面视图。  
　　SharePoint 的核心基于 ASP.NET，并在 IIS 上运行，它可具有多个处理负载平衡的前端 Web 服务器。SQL Server 提供了 SharePoint 网站中存储的数据和文档的完整性、可伸缩性、可靠性和安全性。以下是可伸缩性影响 SharePoint 开发的一些重要方法。  

• API 设计。可伸缩性将驱动 SharePoint 的编程接口的某些特征。当您了解编程接口的设计可提高可伸缩性时，就能更轻松地理解这些接口了。例如，托管客户端对象模型，抽象地说，该模型与 SharePoint Foundation 服务器端对象模型非常类似，但实际上它更为复杂，因为它使您能够在从服务器中检索数据或内容时明确进行控制。
  
• 解决方案设计。可伸缩性将影响您设计基于 SharePoint 构建的解决方案的方式。您必须避免在服务器上导致不必要的计算或查询活动的设计。您必须编写资源消耗量不会多于应有资源消耗量的应用程序。例如，这意味着合理使用协作应用程序标记语言核心架构 和 LINQ to SharePoint 来查询列表项。
  
• 最佳实践。可伸缩性隐藏在作为 SharePoint 开发的最佳实践 的某些编程方法和问题后面。例如，SharePoint 对象模型中的某些对象具有关联的非托管数据。因此，您必须了解并遵循对象处理规则。类似地，在使用 SharePoint 中的大型列表时，可考虑几个最佳实践。如果您不遵循这些规则，则可能会对服务器场产生负面影响。有关详细信息，请参阅 SharePoint Foundation 的最佳做法和 SharePoint Server 的最佳做法。另请参见Best Practices: Using Disposable Windows SharePoint Services Objects （该链接可能指向英文页面）和释放对象。您可使用自动化工具改进您的代码评审。有关详细信息，请参阅使用 SPDisposeCheck 自动执行 SharePoint Dispose() 代码评审（该链接可能指向英文页面）。
  

　　有一些与构建高度可扩展的 Web 应用程序的开发人员所面临的问题相同或类似的问题。我听过这样一个情景，一个 SharePoint 开发人员编写代码以便按设定时间间隔循环访问其网站集中的所有文档并收集要在树控件中显示的信息。这在其测试环境中能够正常工作。但是，代码设计会产生一个与文档和列表项的实际数量相关的性能问题。  
　　可伸缩性通过两种不同的方式影响解决方案设计：  

• 您必须构建可分发的应用程序，这些应用程序在部署到多个前端 Web 服务器上时可正常工作。例如，您可为在本地 XML 文件中存储数据的 Microsoft Business Connectivity Services (BCS) 构建小型 Create/Retrieve/Update/Delete Web 服务（请参阅 Business Connectivity Services）。但是，它在部署到负载平衡服务器场上时将无法正常工作。
  
• 您必须构建可正常执行的应用程序。例如，除非您确定某个列表将包含几个列表项，否则不要使用对象模型循环访问它；而是使用 LINQ to SharePoint，并为 SharePoint 提供优化机会。
  

　　有关 SharePoint 开发与 ASP.NET 开发的相似之处和不同之处的详细信息，请参阅 针对 ASP.NET 开发人员的滑动路径。另请参见 ASP.NET 开发人员的 SharePoint 2010 开发（该链接可能指向英文页面）。  
　　SharePoint Foundation 的最佳做法包含可帮助您避免对性能造成负面影响的缺陷的指南，其中包括有关对象处理、事件接收器、大型文件夹和列表以及代码性能优化的指导。  
　　将 SharePoint 应用程序与数据库应用程序进行比较

　　数据库应用程序开发是用于查看 SharePoint 开发的有利位置之一。SharePoint 网站中的自定义列表与数据库表有很多相同之处。您可使用与列表中的列相关的丰富元数据来定义这些列。此外，SharePoint 列表可有效定义外键，以便您能对包含相关数据的更多有趣方案进行建模。SharePoint 将为删除操作提供级联和限制行为。您可以编程方式或声明方式创建这些列表，也可以编写使用用户定义的列表的程序。这些列表可以是可见的或隐藏的。您可使用 SharePoint 的安全功能来限制访问。  
　　与 SQL 数据库形成直接对比的 SharePoint 的一个方面是，您使用非程序的声明性查询语言来检索数据。不过，将使用 LINQ to SharePoint 或使用通过 XML 编写的协作应用程序标记语言 (CAML)，而不使用 SQL。  
　　SharePoint 与数据库技术的集成程度较深。您可通过 Business Connectivity Services 使用数据库、Web 服务以及几乎任何数据源。这些数据源将表示为外部内容类型。  
　　SharePoint 的数据功能的一个有趣特征是，它不具有事务性保证。例如，您无法确保以下两个操作要么都发生，要么都不发生：在一个表中插入列表项，同时在另一个表中更新列表项。SharePoint 将不会用作实现事务性系统的平台。相反，应在可提供适当保证的外部数据库中实现此类事务性系统。然后，您可通过使用 Business Connectivity Services 在 SharePoint 中显示这些数据。当您设计 SharePoint 应用程序时，您必须考虑此特征。  
　　SharePoint 的数据功能与传统数据库开发的数据功能之间的一个重大区别是，SharePoint 列表（可与数据库表进行比较）不一定是矩形。在 SharePoint 中，内容类型将定义构成列表中的列表项（可与行进行比较）的字段。可将其视为列表项的架构。SharePoint 列表可包含多个内容类型的列表项。下图表示一个包含两个内容类型的项的 SharePoint 列表：LABOR 和 MATERIAL。  
　　图 2. 非矩形 SharePoint 列表
  
　　这将影响您设计和开发使用列表项以及列表项中的字段的应用程序的方式。如果您必须有矩形数据，则可定义列表，使其只能包含一个内容类型。如果您启用非矩形数据，则当您循环访问列表项时，您必须检查内容类型并相应更改代码的行为。  
　　另一个有趣的特征是，由于存在内部实现详细信息，与使用 SQL 查询表相比，使用 LINQ to SharePoint 或 CAML 查询 SharePoint 的速度要慢得多。您不需要创建以下设计，其中的某些列表意外增长到 50,000 或 100,000 个项，并且用户可随意尝试在浏览器中的窗口中显示列表。SharePoint 2010 包含可阻止这类设计导致服务器场关闭的限制功能。但用户界面将会变得无法对用户作出响应。可以通过多种方式处理包含大量项的列表。您必须有意地处理此问题。有关详细信息，请参阅处理大型文件夹和列表。  
　　SharePoint 基于 SQL Server 构建。文档库和 SharePoint 列表存储在数据库中。当您查看 SharePoint 安装的体系结构图时，您会发现这一点。实际 SharePoint 数据库与 SharePoint 开发人员之间并没有特别的关系。您从不直接访问此数据库。您总是使用编程接口来更改网站、列表和文档库。不过，您可使用相同的 SQL Server 安装来承载您直接使用或通过 Business Connectivity Services 使用的数据库。因此，它可以是您用来构建 SharePoint 应用程序的基础结构的一部分。  
　　Microsoft Access 服务允许（但也有限制）您将 Access 数据库发布到 SharePoint 网站。这会带来一些很有用的机会，由于它允许 SharePoint 用户以一致且熟悉的形式共享数据。  将 SharePoint 应用程序与传统的富客户端应用程序进行比较

　　SharePoint 与操作系统有很多共同之处：  

• SharePoint 包含存储。包含文件夹的层次结构的文档库与文件系统中目录中的文件很类似。
  
• SharePoint 具有可编程的用户界面。
  
• 在与操作系统一起使用时，您可编写以不同级别的特权运行的代码。通过使用 SharePoint 开发，您可编写必须使用服务器场管理凭据运行的代码。您可编写在沙盒解决方案中运行的代码，也可编写在客户端浏览器中运行的 JavaScript。
  
• 在与操作系统一起使用时，您可编写服务，这些服务为构建具有复杂动态的 SharePoint 应用程序提供必需的基础结构。
  

　　再次说明一下，规模是最大的差异。规模将驱动 SharePoint 的可编程性特征。您可编写在数百台服务器上以高性能运行的软件，以便为整个企业提供一个可提高协作和工作效率的一致体验。当您从传统应用程序开发转向 SharePoint 开发时，处理可伸缩性问题是您要付出的准入代价。