**摘要：**了解為 Microsoft SharePoint 2010 規劃和開發業務解決方案時必須做出的關鍵點。

上次修改時間：?2012年3月13日

適用范圍：?Business Connectivity Services?| Office 2010?| Open XML?| SharePoint Designer 2010?| SharePoint Foundation 2010?| SharePoint Online?| SharePoint Server 2010?| Visual Studio

本文內容
SharePoint 2010 設計決定概述
作為開發平臺的 SharePoint 2010
將 SharePoint 解決方案包部署為服務器場解決方案與沙盒解決方案
使用 Web 部件、網站頁面或應用程序頁面設計 UI
SharePoint 2010 中的服務器對象模型與客戶端對象模型
訪問 SharePoint 網站中基于列表的內容
在 ECMAScript 和 Silverlight 之間做出選擇
結論
其他資源
關于作者

供稿人：Ted Pattison（該鏈接可能指向英文頁面）?(SharePoint MVP)，Critical Path Training（該鏈接可能指向英文頁面）?| 關于作者

目錄

• SharePoint 2010 設計決定概述

• 作為開發平臺的 SharePoint 2010

• 將 SharePoint 解決方案包部署為服務器場解決方案與沙盒解決方案

• 使用 Web 部件、網站頁面或應用程序頁面設計 UI

• SharePoint 2010 中的服務器對象模型與客戶端對象模型

• 訪問 SharePoint 網站中基于列表的內容

• 在 ECMAScript 和 Silverlight 之間做出選擇

• 結論

• 其他資源

• 關于作者

SharePoint 2010 設計選型概述

本文討論為 Microsoft SharePoint 2010 設計業務解決方案的架構和開發業務解決方案時必須做出的主要設計決定。您將了解何時應該創建面向沙盒的 SharePoint 解決方案，以及何時創建僅支持服務器場級部署的 SharePoint 解決方案。本文還解釋構建需要自定義用戶界面 (UI) 的 SharePoint 解決方案時，如何在 Web 部件、網站頁面和應用程序之間做出選擇。您還將了解如何在使用服務器端對象模型和客戶端對象模型之間做出決定，以及如何選擇適當的技術來訪問 SharePoint 列表中的內容。

作為開發平臺的 SharePoint 2010

SharePoint 技術的發展歷經四個主要產品版本。2001 年的第一個版本和 2003 年的第二個版本得到了順利而適度的采用。不過，從 2007 年的第三個版本開始，SharePoint 技術得到了快速采用，真正開始迅猛發展。全球數以千計的企業、組織和政府機構已經部署了 Microsoft Office SharePoint Server 2007。SharePoint 2010 通過引入新功能和服務在 2007 版本的基礎上進行了改進，這給 SharePoint 技術的繼續發展帶來了美好的前景。

因為經過多年的發展，SharePoint 技術的受歡迎程度已經提高，所以人們希望使用自定義 SharePoint 解決方案自定義內置體驗。而且，Microsoft 繼續在 SharePoint 技術上投資，力求將它轉變為一流的開發平臺。在 2003 版本中，Microsoft 第一次實現了使用自定義 Microsoft .NET Framework 組件（如使用 C# 或 Microsoft Visual Basic 編寫的 Web 部件和事件處理程序）擴展 SharePoint 網站。在 2007 版本中，Microsoft 通過引入面向開發人員的基本構建基塊（如內容類型、網站欄、功能和解決方案包）將 SharePoint 更新為開發平臺。

盡管 SharePoint 2010 的許多新方面改進了 SharePoint 開發人員平臺，但是事實證明最重要的一個方面是稱為 Microsoft Visual Studio 2010 中的 SharePoint 開發工具的新工具集。Visual Studio 2010 中的 SharePoint 開發工具是一個很大的進步，因為它們隱藏并自動完成 SharePoint 開發的許多繁瑣的方面，例如從 SharePoint 項目中的源文件生成解決方案包。通過 Visual Studio 2010 中的 SharePoint 開發工具，還可以方便地將 SharePoint 項目的解決方案包部署到本地服務器場，以便您可以在開發工作站上測試和調試代碼。

Visual Studio 2010 中的 SharePoint 開發工具非常適合初學者和剛剛開始 SharePoint 開發的 .NET 開發人員，因為它使他們可以快速地熟練掌握新技術和提高工作效率。Visual Studio 2010 中的 SharePoint 開發工具還設計為具有可擴展性，這使有經驗的 SharePoint 開發人員可以使用工具集本身不直接支持的高級開發技術。

除了 Visual Studio 2010 中新的支持，SharePoint 2010 開發平臺還引入了一些其他改進。例如，SharePoint 2010 允許您將解決方案包部署為服務器場解決方案或部署為沙盒解決方案。SharePoint 2010 引入了新客戶端對象模型，以補充自 2003 版本以來已成為 SharePoint 開發平臺一部分的服務器端對象模型。SharePoint 2010 還引入了訪問 SharePoint 列表中的內容的新選項，包括 LINQ（語言集成查詢）支持和基于 REST 的 Web 服務。

具有不同的選項固然很好，但您任何時候都不可能使用所有這些選項。事實上，每次開始為特定應用場景設計新 SharePoint 解決方案時，您都必須在這些選項之間做出選擇。下面各節介紹要考慮的關系最密切的設計問題，以便您可以在設計和開發新 SharePoint 解決方案時作出最佳選擇。

將 SharePoint 解決方案包部署為服務器場解決方案與沙盒解決方案

SharePoint 開發中的一個基本概念是解決方案包。在物理級別，解決方案包是一個 CAB 存檔，它包含在 SharePoint 環境中部署自定義開發成果所需的文件和元數據。從設計的角度來看，解決方案包是用于重用、測試和部署的基本單位。解決方案包還提供可用于將更新推送到 SharePoint 場以修復錯誤并擴展已部署的解決方案的粒度。

在 SharePoint 2010 中可以通過兩種方式部署解決方案包：部署為服務器場解決方案或部署為沙盒解決方案。每次使用 Visual Studio 2010 中的 SharePoint 開發工具創建新 SharePoint 項目時，都會強制您選擇將代碼作為沙盒解決方案還是作為服務器場解決方案進行開發和測試。您的決定應該基于是要開發和測試 SharePoint 解決方案以僅支持服務器場級部署，還是要將它作為可以靈活地部署為服務器場解決方案或沙盒解決方案的 SharePoint 解決方案進行測試。

部署為服務器場解決方案的解決方案包必須由服務器場管理員部署。因為服務器場解決方案部署需要將自定義文件復制到服務器場中的每個 Web 服務器上，所以會對服務器場的運行狀況帶來一定風險。此外，大多數服務器場解決方案在 Web 服務器上的全局程序集緩存中安裝自定義程序集 DLL，這允許內部的代碼在完全信任級別運行。因此，許多服務器場管理員要求對 SharePoint 解決方案進行冗長的代碼檢查和嚴格的測試過程，然后再將其部署到生產場。有些 SharePoint 環境中的服務器場管理員要求更甚，完全禁止 SharePoint 解決方案的服務器場級部署。

SharePoint 2010 引入了新的沙盒體系結構，能提供有價值的服務器場級部署替代方法。與服務器場解決方案部署不同，沙盒解決方案部署不需要服務器場管理員的批準或協助。相反，作為沙盒解決方案開發的 SharePoint 解決方案可以由網站集所有者或網站管理員角色中的業務用戶上載和激活。這樣可大大加快自定義 SharePoint 解決方案投入使用的過程。通過沙盒解決方案還可以開發面向不允許服務器場解決方案部署的環境（如 SharePoint Online）的自定義解決方案。

關于新沙盒體系結構，有一點非常重要但卻常被誤解。將 SharePoint 解決方案作為沙盒解決方案設計和開發并不意味著必須始終將它部署為沙盒解決方案。相反，您可以將面向沙盒開發的 SharePoint 解決方案部署為沙盒解決方案或部署為服務器場解決方案。這意味著將 SharePoint 解決方案作為沙盒解決方案開發可以在各種部署方案中提供更大的靈活性。

我們來看一個沙盒解決方案如何提供這種靈活性的示例。在不允許服務器場級解決方案部署的 SharePoint 場中，具有網站管理員權限的用戶可在網站集上下文內上載和激活 SharePoint 解決方案。在另一個沒有這些限制的 SharePoint 場中，相同的 SharePoint 解決方案可部署為服務器場解決方案，這樣就能獲得更高級別的性能和可維護性。這樣，當沙盒的約束不會阻止您完成所需操作時，您就會有面向沙盒的設計動機。

沙盒解決方案的限制

決定是否應該將 SharePoint 解決方案作為沙盒解決方案開發時，關鍵是了解沙盒中允許的操作和禁止的操作。例如，不允許沙盒解決方案將文件部署到 Web 服務器的文件系統。這意味著沙盒解決方案不能包含以下任一內容：

• 安裝在全局程序集緩存中的程序集

• 在服務器場級別激活的功能

• 在 Web 應用程序級別激活的功能

• 應用程序頁面

• 用戶控件

• 可視 Web 部件

• 順序工作流模板

• 狀態機工作流模板

• Business Data Connectivity (BDC) Service 模型

在可以使用服務器端代碼執行的操作方面也有重要限制。盡管沙盒解決方案可以包含使用服務器端對象模型的代碼，但服務器端對象模型的許多部分仍被禁止使用。例如，沙盒解決方案中的代碼不能訪問服務器端對象模型中當前網站集范圍之外的任何內容。不能使用 SPSite 類創建新對象以訪問其他網站集。此外，不允許訪問服務器端對象模型的服務器場級別的任何方面，如 SPFarm 對象或 SPWebApplication 對象。

以下列表顯示只有在服務器場解決方案中部署代碼時才能完成的常見編程任務：

• 創建和配置 Web 應用程序

• 創建和配置內容數據庫

• 創建網站集

• 聚合存儲在兩個或更多網站集中的內容

除了服務器端對象模型的編程限制，沙盒體系結構還進一步限制您使用 Microsoft .NET Framework 提供的許多類庫。SharePoint Foundation 通過在使用代碼訪問安全性 (CAS) 設置初始化的獨立工作進程中運行沙盒代碼來強制實施這些限制。例如，不能訪問?System.IO?命名空間中的任何類。此外，沙盒解決方案中的服務器端代碼不能訪問允許您通過網絡訪問資源的任何 .NET Framework 部分。這意味著您無法連接到數據庫、進行出站 Web 服務調用，甚至無法發出簡單的 HTTP GET 請求。

顯而易見，沙盒對您可以在服務器端代碼中執行的操作設置了重要限制。代碼可以訪問內容的唯一位置是在上載并激活沙盒解決方案的網站集中。這些限制可能會強制您在開發需要通過網絡訪問資源（如 Web 服務和數據庫）的 SharePoint 項目時重新考慮您的設計。

在需要訪問網絡資源的方案中，可能應該選擇服務器場解決方案而不是沙盒解決方案。不過，可以考慮另外一個選項。盡管沙盒解決方案體系結構限制服務器端代碼可以執行的操作，但是它不對客戶端代碼施加任何限制。因此，您可以使用在可以訪問網絡資源的 ECMAScript（JavaScript、JScript）或 Microsoft Silverlight 應用程序中編寫的客戶端代碼來設計沙盒解決方案。在本文中我們將繼續討論該設計選項。

?備注

Microsoft 使用術語 JavaScript 而不是 JavaScript。有關詳細信息，請參閱下文中的 SharePoint 客戶端對象模型如何工作？一節。

沙盒解決方案的常見開發應用場景

對許多類型的 SharePoint 項目來說，對沙盒解決方案設置的限制通常過于嚴格。不過，有一些簡單業務解決方案類別完全可以使用沙盒解決方案實現。下面是使用沙盒解決方案可以滿足的要求列表：

• 創建自定義網站欄、內容類型和列表定義

• 創建列表并添加用于數據驗證的事件處理程序

• 在"快速啟動"菜單和頂部導航欄上創建導航節點

• 添加查詢和更新列表的 Web 部件

• 添加網站頁面以托管 Web 部件和 Silverlight 應用程序

• 使用自定義母版頁、CSS 文件和圖像確立 SharePoint 網站的品牌

使用 Web 部件、網站頁面或應用程序頁面設計 UI

在 SharePoint 項目中設計 UI 時要考慮一些重要設計問題。例如，是否應該使用 Web 部件、網站頁面模板或應用程序頁面創建 UI 元素？在用于創建自定義 UI 元素的這三種技術中，每種技術在特定應用場景中都具有勝于其他兩種技術的優勢。不過，您可能會發現每種方法非常適用的其他方案，這意味著決定使用哪種方法完全取決于開發人員的個人喜好。

認真思考手頭的設計方案，并問自己以下問題：

• 是否需要支持用戶自定義和個性化？

• 是否擔心賦予用戶的控制權太多？

• UI 是否需要用 C# 或 Visual Basic 編寫的服務器端代碼？

• 是否需要使用沙盒解決方案部署 UI？

支持網頁的用戶自定義

首先討論第一個問題 — 是否需要支持用戶自定義和個性化。如果是，則最佳選擇是使用 Web 部件構建 UI。這是因為 SharePoint Foundation 使用戶能夠添加、自定義、個性化和刪除 Web 部件。許多曾經使用過 SharePoint 技術的用戶非常擅于向頁面添加 Web 部件，并通過瀏覽器中的任務窗格自定義它們。

網站頁面也提供某種程度的用戶自定義支持，但是不如 Web 部件簡單。例如，用戶不能使用瀏覽器自定義網站頁面的基礎內容，而是必須依賴于與 SharePoint 兼容的頁面編輯工具，如 Microsoft SharePoint Designer 2010。不過，您應該知道，使用 SharePoint Designer 2010 修改網站頁面需要理解復雜的主題，如 HTML 編輯、服務器端控件和母版頁。因此，網站頁面自定義應該僅限于涉及的高級用戶可以熟練使用 SharePoint Designer 2010 設計 SharePoint 頁面的應用場景。

如果您決定使用 Web 部件構建 UI，則應該考慮如何將這些 Web 部件添加到 SharePoint 網站中的頁面。最簡單的方法只涉及創建 Web 部件，而不涉及任何其他操作。這是用戶需要向現有 Web 部件頁面添加 Web 部件實例的相當常見的應用場景。更完善的方法涉及在功能激活期間自動完成向網站頁面添加 Web 部件的工作。

在 SharePoint 解決方案中創建 Web 部件時，應考慮是否需要另外創建頁面以托管 Web 部件。如果您認為應該這樣做，則不能使用應用程序頁面，因為它們不支持 Web 部件。而是必須設計一個或多個滿足 Web 部件頁面要求的網站頁面模板。創建網站頁面模板后，可以將它添加到 SharePoint 解決方案的模塊中，以便在功能激活期間創建新網站頁面實例。最后一步是使用 Web 部件實例預先填充網站頁面。為此，您可以在 File 元素內部添加 AllUserWebPart 元素，這將在功能激活期間創建網站頁面。

控制 UI 自定義

現在，我們來考慮第二個問題。您是否擔心賦予用戶的網站控制權太多？許多開發人員害怕喜歡嘗試并且常常惹麻煩的粗心大意的用戶。例如，假定您的 UI 設計涉及具有 Web 部件的網站頁面。有什么方法可以防止特權用戶和被誤導的用戶將頁面置于編輯模式然后刪除 Web 部件？您可以想象這可能導致撥打支持電話，并且 SharePoint 網站在一段時間內不可用，直到具有更多專業技能的人員介入，將適當的 Web 部件重新添加到頁面。

應用程序頁面不支持任何形式的用戶自定義。因此，在希望鎖定 UI 的設計中使用它們可能非常有利。嘗試鎖定使用網站頁面和 Web 部件構建的 UI 可能很繁瑣，在用戶具有網站所有者權限的應用場景中通常不可行。

在 UI 后臺使用服務器端代碼

要考慮的下一問題是是否要在 UI 后臺編寫服務器端代碼。如果要，則必須選擇 Web 部件或應用程序頁面。更具體地說，應該避免在網站頁面和網站頁面模板中編寫服務器端代碼。這是因為網站頁面必須支持安全模式處理，這會阻止用 C# 或 Visual Basic 編寫的內嵌代碼。盡管從技術上講可以使用 C# 或 Visual Basic 創建自定義基類并在網站頁面模板中從此基類繼承，但是不建議使用這種方法。它可能非常麻煩，很少用于 SharePoint 開發，因為向 Web 部件或在應用程序頁面后臺添加服務器端代碼容易得多。

將 UI 部署為沙盒解決方案

設計自定義 UI 時要考慮的另一重要問題是是否需要支持部署為沙盒解決方案。如果是，則必須避免使用不能由沙盒解決方案正確部署的應用程序頁面。這意味著必須使用網站頁面和 Web 部件構建 UI。

SharePoint 2010 中的服務器對象模型與客戶端對象模型

從 2003 版本開始，SharePoint 向開發人員提供了服務器端對象模型，以訪問網站中的內容和在網站級別執行各種管理任務，如創建列表、添加導航節點和配置權限。通過服務器端對象模型還可以在服務器場級別執行管理任務，如創建和配置 Web 應用程序及內容數據庫。

服務器端對象模型通過名為 Microsoft.SharePoint.dll 的程序集提供，該程序集部署在 SharePoint 場中的每個服務器上。這意味著開發在 Web 服務器上運行的 SharePoint 組件（如功能接收器、事件處理程序、Web 部件、應用程序頁面和工作流模板）時，可以使用服務器端對象模型。不過，服務器端對象模型不能直接用于在不屬于 SharePoint 場的計算機上運行的應用程序和組件。

SharePoint 2010 引入了新客戶端對象模型，它允許通過網絡訪問 SharePoint 網站。例如，您可以使用客戶端對象模型在可以通過網絡連接到 SharePoint 網站的桌面應用程序中編寫代碼。使用客戶端對象模型連接到 SharePoint 網站后，您可以讀取和更新列表和文檔庫中的內容。還可以在網站中執行管理任務，如創建新列表、添加導航節點和配置用戶權限。

客戶端對象模型可以有效地用于多種類型的應用程序。例如，通過客戶端對象模型，您可以使用 Windows Forms 和 Windows Presentation Foundation (WPF) 開發在 SharePoint 網站中讀取和寫入內容的桌面應用程序。客戶端對象模型還非常適用于編寫在瀏覽器中的頁面后臺運行的客戶端代碼，如自定義 JavaScript 代碼或 Silverlight 應用程序。

使用客戶端對象模型的主要好處是它可以顯著改進用戶體驗。這是因為您可以編寫在用戶計算機上執行的代碼，這樣不再需要回發和混亂的頁面切換。例如，可以在命令按鈕后臺編寫客戶端代碼，以更新 SharePoint 網站中的列表項，然后刷新 UI 以反映此更改。重要的是，在執行這項工作時，不會強制用戶忍受頁面切換或回發。

SharePoint 客戶端對象模型如何工作？

SharePoint 2010 中的客戶端對象模型基于 Windows Communication Foundation (WCF) 構建，WCF 用于在客戶端計算機和 Web 服務器之間建立通信。SharePoint Foundation 使用名為 Client.svc 的 WCF Web 服務文件在服務器場中的每個 Web 服務器上提供一個客戶端對象模型的入口點。

請注意，無需理解 WCF 的工作原理即可使用客戶端對象模型。實際上，客戶端對象模型專門設計用于對 SharePoint 開發人員隱藏 WCF 管道的基礎詳細信息。使用客戶端對象模型時，您只需創建對象并訪問它們的方法和屬性。客戶端對象模型提供客戶端運行庫，該運行庫使用 WCF Web 服務調用處理與 Web 服務器的通信。

可以從三種類型的客戶端應用程序訪問客戶端對象模型，它們是 .NET Framework 應用程序、Silverlight 應用程序和在 SharePoint 網站中的頁面上運行的 JavaScript 代碼。如果要開發 .NET Framework 應用程序，則可以通過引用以下程序集訪問客戶端對象模型：

• Microsoft.SharePoint.Client.dll

• Microsoft.SharePoint.Client.Runtime.dll

請注意，除使用客戶端對象模型的任何 .NET Framework 應用程序外，還必須部署這兩個程序集。如果在運行時不能加載這兩個程序集，則使用客戶端對象模型編寫的 .NET Framework 應用程序將無法正確運行。

如果要開發 Silverlight 應用程序，則可以通過引用以下程序集訪問客戶端對象模型：

• Microsoft.SharePoint.Client.Silverlight.dll

• Microsoft.SharePoint.Client.Silverlight.Runtime.dll

請注意，每次 Silverlight 應用程序開始使用客戶端對象模型時，這兩個程序集都必須可加載到瀏覽器的進程中。不過，部署這兩個程序集的步驟由 Visual Studio 2010 自動處理。創建新 Silverlight 項目并添加對這兩個程序集的引用時，Visual Studio 2010 會配置項目的生成過程以自動將這兩個程序集嵌入用于部署 Silverlight 應用程序的 .xap 文件中。這使您能夠隨依賴這些程序集的任何 Silverlight 應用程序部署這些程序集。

現在該討論從自定義 ECMAScript（JavaScript、JScript）代碼使用客戶端對象模型了。首先要了解的是 Microsoft 使用術語 JavaScript 而不是 JavaScript。例如，本文提到 JavaScript 客戶端對象模型。不要因為術語 JavaScript 而感到困惑。它是可以與 JavaScript 互換使用的術語。

如果在 SharePoint 網站中的頁面上編寫客戶端 JavaScript 代碼，則可以通過名為 sp.js 的標準庫文件訪問 JavaScript 客戶端對象模型，該文件部署在服務器場中的每個 Web 服務器上。在開始使用 JavaScript 客戶端對象模型之前，必須確保 sp.js 已下載并且可供頁面使用。為此，您可以在 JavaScript 中調用 ExecuteOrDelayUntilScriptLoaded 方法并傳遞自定義函數名稱和 sp.js 的文件名。

復制

ExecuteOrDelayUntilScriptLoaded(MyEcmaScriptCode, "sp.js");function MyEcmaScriptCode() {// This code will not execute until sp.js is fully downloaded. }

?備注

SharePoint 中的許多標準 JavaScript 庫文件（如 sp.js）都配置為在頁面已顯示給用戶之后按需加載。這種新的延遲加載技術是在 SharePoint 2010 中引入的，以提供響應速度更快的 UI 體驗。不過，開發人員對延遲加載還存在顧慮。問題在于，如果在文件尚未下載到瀏覽器時嘗試訪問 sp.js 中的任何內容，則會遇到運行時錯誤。

對 ExecuteOrDelayUntilScriptLoaded 的調用強制托管頁面在嘗試執行自定義函數之前完全下載 sp.js。這是可用于確保客戶端 JavaScript 代碼可以成功調用 sp.js 并開始使用客戶端對象模型的一種技術的示例。

異步執行客戶端對象模型方法

開始使用客戶端對象模型時，您通常會發現不能使用同步行為對 Web 服務器執行方法。這是因為同步調用會占用主要 UI 線程，并導致凍結 UI，直到方法調用返回。在應用程序設計中，通過網絡進行調用時凍結 UI 通常無法讓人接受。因此，必須了解如何異步對 Web 服務器執行方法。

例如，開發使用客戶端對象模型的 Silverlight 應用程序時，應該始終使用 ExecuteQueryAsync 方法異步調用 Web 服務器。調用 ExecuteQueryAsync 方法時，必須將委托引用傳遞給回調方法。這些回調方法在調用從 Web 服務器返回時執行。以下代碼示例演示編寫為與 Web 服務器異步交互的簡單 Silverlight 應用程序。

C#復制

public partial class MainPage : UserControl {protected ClientContext clientContext;protected Web site;public MainPage() {InitializeComponent();clientContext = new ClientContext("http://intranet.wingtip.com");site = clientContext.Web;clientContext.Load(site);clientContext.ExecuteQueryAsync(OnSucceed, OnFail);}void OnSucceed(object sender, ClientRequestEventArgs args) {// Callback method that executes when there are no errors.}void OnFail(object sender, ClientRequestEventArgs args) {// Callback method that executes when there are errors.} }

開發人員面臨的另一難題涉及在回調方法中編寫用于處理線程切換的代碼。使用客戶端對象模型時需要這樣做，因為回調方法在輔助線程上執行，而輔助線程不能訪問 UI 中的控件，如文本框和數據網格。關鍵點在于開發人員負責將執行流從輔助線程切換回主 UI 線程。執行流切換到主 UI 線程后，可以更新控件。下面的示例演示如何使用 Silverlight 應用程序中的 Dispatcher.BeginInvoke 方法進行線程切換以更新文本框控件。

C#復制

void OnSucceed(object sender, ClientRequestEventArgs args) {// Running on secondary thread.Dispatcher.BeginInvoke(delegate() {// Running on primary UI thread.txtDisplay.Text = "Site ID = " + site.Id.ToString();}); }

從這些示例中您可能會發現，使用客戶端對象模型需要高級編程技能。因此，使用客戶端對象模型開發可能更適合高級開發人員，而不是初學者。

訪問 SharePoint 網站中基于列表的內容

SharePoint 2010 提供了用于訪問 SharePoint 網站中基于列表的內容的多種不同選項。您可以在服務器端代碼中使用?SPQuery?對象或?SPSiteDataQuery?對象訪問列表中的項。還可以決定使用新 LINQ to SharePoint 支持編寫查詢和更新列表項的服務器端代碼。說到編寫客戶端代碼，客戶端對象模型和基于 REST 的新 Web 服務提供了另外兩個選項。本節介紹上述每種技術，并討論它們的相對優點和缺點。

在 2003 版本中，Microsoft 在服務器端對象模型中引入了 SPQuery 類，以提供一種查詢 SharePoint 列表中的項的途徑。使用 SPQuery 類要求開發人員集中分析 XML 片段，以便采用稱為協作應用程序標記語言 (CAML) 的語言參數化查詢。下面是一個典型示例，演示使用 SPQuery 對象對 SharePoint 列表執行查詢需要執行的操作。

C#復制

SPList contacts = this.Web.Lists["Contacts"]; SPQuery query = new SPQuery(); query.ViewFields = "<FieldRef Name='Title'/>" + "<FieldRef Name='FirstName'/>" +"<FieldRef Name='Email'/>" + query.Query = @"<Where><BeginsWith><FieldRef Name='FirstName'/><Value Type='Text'>B</Value></BeginsWith></Where><OrderBy><FieldRef Name='Title'/><FieldRef Name='FirstName'/> </OrderBy>";SPListItemCollection results = contacts.GetItems(query); foreach (SPListItem item in results) {// Enumerate through items.string FirstName = item["FirstName"].ToString() }

SPQuery 類非常有用，因為它提供在編寫服務器端代碼時對大型列表運行查詢的有效方式。使用 SPQuery 對象的主要不利因素與開發人員工作效率相關。Visual Studio 2010 在集中分析所需 CAML 片段方面不提供任何幫助。這通常導致開發人員通過頻繁復制并粘貼工作示例中的 CAML 片段來重用技術，這樣做效率很低。不過，還存在以下問題：對列值的訪問未強類型化，而是必須通過以字符串形式傳遞列名稱來讀取和寫入列值。

string s = item["Title"].ToString()

缺少用于訪問列表中的列值的強類型化技術產生了一些值得注意的不利因素。C# 編譯器和 Visual Basic 編譯器無法確定列名稱拼寫錯誤的情況。編譯器還無法確定開發人員是否已正確將列值轉換為正確的類型。這會導致只有在測試階段才能發現的錯誤。缺少強類型化的列訪問還導致在選擇要訪問的列時 Visual Studio 2010 無法通過 IntelliSense 提供任何幫助。

在 2007 版本中，Microsoft 添加了 SPSiteDataQuery 類以補充 SPQuery 類。SPSiteDataQuery 類允許開發人員執行將多個列表中的項聚合到單個結果集中的查詢。例如，假定您要運行單個查詢，該查詢可以查找并聚合當前網站集中所有聯系人列表中的聯系人。您可以使用 SPSiteDataQuery 對象來運行以下查詢，該對象將查詢范圍設置為當前網站集并提供基于 Contact 內容類型的 where 子句。

C#復制

SPSiteDataQuery query = new SPSiteDataQuery(); query.Webs = "<Webs Scope='SiteCollection' />"; query.ViewFields = "<FieldRef Name='Title'/>" + "<FieldRef Name='FirstName'/>" +"<FieldRef Name='Email'/>"; query.Query = @"<Where><FieldRef Name='ContentType'/><Value Type='Computed'>Contact</Value></Where>"; DataTable results = this.Web.GetSiteData(query); foreach (DataRow item in results.Rows) {// Enumerate through items.string FirstName = item["FirstName"].ToString() }

能夠運行聚合多個列表中的項的查詢毫無疑問使 SPSiteDataQuery 具備了優于其他列表訪問技術的獨特功能。因此，在需要聚合的應用場景中，它對 SharePoint 開發人員非常有用。不過，SPSiteDataQuery 類與 SPQuery 類一樣，都會對開發人員的工作效率產生不利影響，因為它強制開發人員集中分析 CAML 片段，并且它不提供對列值的強類型化訪問。

SPSiteDataQuery 類的另一個潛在問題是它可能導致效率很低的查詢，這類查詢花費很長時間運行并且消耗 Web 服務器的大量處理周期。因此，在使用 SPSiteDataQuery 類時，應確保充分執行性能測試。還應該考慮避免在訪問頻率較高的頁面（如網站的主頁）的后臺使用 SPSiteDataQuery 類。

使用 LINQ to SharePoint 提供程序支持

Microsoft 在 SharePoint 2010 中引入了一項支持，該支持允許服務器端代碼使用 LINQ（語言集成查詢）針對 SharePoint 列表執行查詢。該支持由作為 SharePoint Foundation 中的標準組件安裝的 LINQ to SharePoint 提供程序實現。

使用 LINQ to SharePoint 提供程序訪問 SharePoint 列表中的項的主要優勢是提高了開發人員的工作效率。使用 LINQ 訪問 SharePoint 列表時，無需使用 CAML。相反，您可以直接使用 C# 或 Visual Basic 編寫 where 子句和 order by 子句。

通過使用 LINQ，還能夠以強類型化的方式針對列值進行編程。這允許編譯器在開發人員出現列名稱或列類型錯誤時生成錯誤。LINQ 的強類型化特性還使 Visual Studio 2010 可以向 IntelliSense 提供一個下拉列表，以列表形式顯示所有可用列。

檢查編寫為針對 SharePoint 列表執行 LINQ 查詢的以下代碼，并將它與前面所示的使用 CAML 的示例進行比較。

C#復制

WingtipSiteDataContext dc = new WingtipSiteDataContext(this.Web.Url); var query = from contact in dc.Contactswhere contact.FirstName.StartsWith("B")orderby contact.LastNameselect contact; foreach (var item in query) {// Enumerate through items.string FirstName = item.FirstName; }

LINQ to SharePoint 提供程序還可以在向 SharePoint 列表添加新項時提高開發人員的工作效率。與查詢列表項時一樣，LINQ to SharePoint 提供程序在您向新列表項分配列值時啟用強類型化和 IntelliSense。下面是使用 LINQ 支持添加新列表項的一個示例。

C#復制

WingtipSiteDataContext dc = new WingtipSiteDataContext(this.Web.Url); Contact newContact =new Contact {FirstName = "Wendy",LastName = "Wheeler"EMail = "wendy@wheeler.com"}; dc.Contacts.InsertOnSubmit(newContact); dc.SubmitChanges();

顯而易見，LINQ to SharePoint 提供程序向需要查詢和更新 SharePoint 列表項的開發人員提供了明確的好處。不過，您應該了解 LINQ to SharePoint 提供程序實際上只表示 CAML 上的生產效率層。在后臺，LINQ to SharePoint 提供程序將 LINQ 查詢語句轉換為 CAML 然后使用 CAML 對內容數據庫執行這些查詢。因此，結合使用 CAML 和 SPQuery 類或 SPSiteDataQuery 類無法完成的操作實際上使用 LINQ to SharePoint 提供程序也無法完成。不過，反過來說則不盡然。使用 LINQ 無法完成的一些操作可以使用 SPQuery 類和 SPSiteDataQuery 類來完成。

使用 LINQ to SharePoint 提供程序的一個問題是您必須提前了解列的情況。在編寫使用 LINQ to SharePoint 提供程序的代碼之前，必須首先運行 spmetal.exe 實用工具以生成 LINQ 編程中所需的實體類。這導致在代碼必須在運行時發現列表中的列名稱和類型的應用場景中，無法使用 LINQ。

另一個問題是 LINQ to SharePoint 提供程序不支持與 SPSiteDataQuery 類及其功能（運行將網站集中多個列表中的項聚合在一起的查詢）相匹配的任何行為。相反，必須使用 LINQ to SharePoint 提供程序運行多個查詢，然后編寫您自己的代碼將結果聚合在單個結果集中。

有關 LINQ to SharePoint 提供程序的最后一點說明是目前它不提供禁用限制的方法。這意味著使用 LINQ to SharePoint 提供程序執行的查詢面臨以下風險：返回的項數超過當前 Web 應用程序的限制閾值時失敗。使用 SPQuery 類或 SPSiteDataQuery 類執行查詢時無限制，因為您可以通過將 QueryThrottleMode 屬性設置為值 Override 來禁用限制。

C#復制

SPQuery query = new SPQuery(); query.QueryThrottleMode = SPQueryThrottleOption.Override;

現在我們已經介紹了用于通過服務器端代碼訪問 SharePoint 列表的技術。不過，某些 SharePoint 設計方案更適合使用客戶端代碼而不是服務器端代碼。因此，您還應該了解用于通過網絡查詢 SharePoint 列表項的選項有哪些。一個選項是使用客戶端對象模型訪問 SharePoint 列表。另一選項是使用 SharePoint Foundation 附帶的基于 REST 的新 Web 服務。下一節將分析這兩種技術，以便將它們與您剛剛了解的服務器端技術相比較。

使用 SharePoint 客戶端對象模型訪問列表項

客戶端對象模型為可以在網站集中完成的操作提供了各種功能。例如，您可以使用客戶端對象模型編寫用于添加用戶、創建列表和配置權限的代碼。除了這種類型的功能，客戶端對象模型還提供讀取和寫入列表項的功能。

對查詢列表項的客戶端對象模型支持通過 CamlQuery 類實現。顧名思義，使用 CamlQuery 運行查詢需要您依照 CAML 工作，如以下示例所示。

C#復制

clientContext = new ClientContext("http://intranet.wingtip.com"); site = clientContext.Web; clientContext.Load(site); List contactsList = site.Lists.GetByTitle("Contacts"); clientContext.Load(contactsList); CamlQuery query = new CamlQuery(); query.ViewXml = @"<View><Query><FieldRef Name='Title' /><FieldRef Name='FirstName'/><FieldRef Name='Email'/><Where><BeginsWith><FieldRef Name='FirstName'/><Value Type='Text'>B</Value></BeginsWith></Where></Query></View>"; ListItemCollection contactsCollection; contactsCollection = contactsList.GetItems(customersQuery); clientContext.Load(contactsCollection); clientContext.ExecuteQueryAsync(OnSucceed, OnFail);

使用客戶端對象模型查詢和更新列表項具有與使用 SPQuery 類和 SPSiteDataQuery 類相同的一些不利因素。即，您需要集中分析 CAML 片段。這意味著編譯器無法捕獲 CAML 片段中的任何錯誤。此外，編寫查詢時不能獲得任何 IntelliSense 幫助。

使用基于 REST 的 Web 服務訪問 SharePoint 列表項

用于查詢和更新列表項的最后一種技術涉及使用 SharePoint Foundation 中內置的基于 REST 的新 Web 服務。基于 REST 的這一 Web 服務使用名為 ListData.svc 的 WCF Web 服務文件公開，該文件可通過 _vti_bin 目錄訪問。通過 ListData.svc，可以基于在末尾包含列表標題的相對于網站的 URL，使用簡單的 HTTP GET 請求訪問 SharePoint 列表中的項，如以下示例所示。

http://intranet.wingtip.com/\_vti\_bin/ListData.svc/Contac

使用基于 REST 的 Web 服務的一個好處是它可以從幾乎任意類型的客戶端（包括瀏覽器）訪問。另一相關好處是任何命令都可以通過追加查詢字符串參數化為目標 URL。創建 URL 以通過 ListData.svc 訪問列表項時，可以添加 QueryString 參數以選擇字段并控制篩選和排序，如以下示例所示。

ListData.svc/Contacts()?$select=FirstName,LastName

ListData.svc/Contacts()?$filter=startswith(FirstName, 'B')

ListData.svc/Contacts()?$orderby=FirstName

使用 ListData.svc 的另一重要好處是它會生成符合新出現的 Web 協議（如 Atom 發布協議 (AtomPub) 和開放式數據協議 (OData)）的 XML 響應。將 OData 標準化為客戶端和 Web 服務之間的協議在 Microsoft 內和整個行業中越來越常用。它的普遍應用是因為它能夠提供一種簡單的標準化方式來公開和訪問各種數據源（如關系數據庫、文件系統、標準網站以及現在的 SharePoint 列表）中的內容。

SharePoint 團隊使用 WCF Data Services 實現基于 REST 的 Web 服務，這一點也非常重要。SharePoint 與 WCF Data Services 的集成帶來了新的好處，因為它使您能夠使用 LINQ 查詢語句檢索 SharePoint 列表項。此外，它還允許您使用強類型化屬性訪問列值。這會產生類似于使用 LINQ to SharePoint 提供程序的開發人員體驗，因為編譯器和 IntelliSense 在您編寫查詢時可提供額外的幫助。

若要在 Visual Studio 2010 項目中創建服務引用，您必須傳遞指向 ListData.svc 的相對于網站的 URL。當 Visual Studio 2010 從 ListData.svc 創建服務引用時，它會生成包含網站的數據上下文類和每個列表的 LINQ 兼容實體類的代碼。數據上下文類基于 DataServiceQuery 類為每個列表公開一個屬性，這樣您就可以使用 LINQ 查詢語句執行遠程查詢，如以下示例所示。

C#復制

String url = "http://intranet.wingtip.com/_vti_bin/ListData.svc"; WingtipSiteDataContext dc = new WingtipSiteDataContext(new Uri(url)); var query = from contact in dc.Contactswhere contact.FirstName.StartsWith("B")select contact; foreach (var item in query) {// Strongly typed access to column value.string FirstName = item.FirstName; }

如果計劃從 JavaScript 代碼或在瀏覽器中運行的 Silverlight 應用程序調用 ListDava.svc，則還必須了解如何異步執行查詢。下面是 Silverlight 應用程序的一個示例，該應用程序使用針對 ListDava.svc 創建的服務引用異步執行遠程查詢。

C#復制

public partial class MainPage : UserControl {String url = "http://intranet.wingtip.com/_vti_bin/ListData.svc";protected WingtipSiteDataContext dataContext;protected DataServiceQuery<ContactsItem> ContactsQuery;public MainPage() {InitializeComponent();dataContext = new WingtipSiteDataContext(new Uri(url)); ContactsQuery = (from contact in dataContext.Contactswhere contact.FirstName.StartsWith("B")select contact) as DataServiceQuery<ContactsItem>;ContactsQuery.BeginExecute(DisplayContacts, null);}public void DisplayContacts(IAsyncResult result) {Dispatcher.BeginInvoke(delegate(){var queryResults = ContactsQuery.EndExecute(result);foreach (var contact in queryResults) {// Access columns using strongly typed properties.string FirstName = customer.FirstName;} });} }

請注意，以下示例實現了 DisplayContacts 回調方法，以使用前面討論的 Dispatcher.BeginInvoke 方法執行線程切換。針對 ListData.svc 異步執行查詢類似于使用客戶端對象模型，因為您必須在更新 UI 中的任何控件之前將回調方法的執行切換回主線程。

在 ECMAScript 和 Silverlight 之間做出選擇

在現代 Web 應用程序設計中，添加客戶端代碼的要求越來越普遍。畢竟，具有豐富客戶端行為的網站現在已經成為 Internet 上的標準。向 SharePoint 解決方案添加客戶端代碼無疑是改進用戶體驗的一種方法。

除了改進用戶體驗之外，在一些 SharePoint 設計方案中，客戶端代碼還可以執行服務器端代碼無法執行的操作。我們來分析一個簡單的示例。假定您需要開發一個沙盒解決方案，以便從 Internet 上的公共 Web 服務檢索內容，然后將這些內容寫入 SharePoint 列表。在沙盒解決方案中使用服務器端代碼存在的問題是無法調用 Web 服務。

不過，您可以重新設計沙盒解決方案以包含直接從用戶瀏覽器調用 Web 服務的自定義 JavaScript 代碼或 Silverlight 應用程序。客戶端代碼從 Web 服務檢索內容后，即可使用客戶端對象模型或 ListData.svc 將這些內容寫入 SharePoint 列表。本例還提供了為什么可能要在 SharePoint 解決方案中包含客戶端代碼的另一動機。

如果您決定向 SharePoint 解決方案添加客戶端代碼，則下一步是選擇在頁面后臺編寫自定義 JavaScript 代碼，或者開發一個或多個 Silverlight 應用程序。我們來看一下每種方法的利弊。

JavaScript 具有適用范圍大于 Silverlight 的優勢，因為它在更多瀏覽器中受支持。此外，瀏覽器包含對 JavaScript 的內置支持，而在用戶下載并安裝 Silverlight 運行庫之前 Silverlight 應用程序無法運行。盡管下載并安裝 Silverlight 運行庫可以通過 Internet 在幾秒鐘內完成，您仍然必須承認，Silverlight 開發假定用戶將信任 Microsoft 軟件組件并通過 Internet 進行安裝。在覆蓋范圍很廣的方案中做出這種假設可能不合適，例如在開發面向 Internet 的商用應用程序時，此時您希望覆蓋最大數量的潛在用戶。

在大多數 SharePoint 2010 環境中，通常可以假定隨 SharePoint 解決方案部署 Silverlight 應用程序不會導致問題。畢竟，SharePoint Foundation 在標準頁面（例如，通過選擇"網站操作"菜單上的"其他選項"命令獲得的創建頁面）中包含一些不同的 Silverlight 3 應用程序。

SharePoint 2010 用戶需要安裝 Silverlight 3 才能獲得完整內置體驗這一事實意味著，通常可以假定他們已在計算機上安裝 Silverlight 3 運行庫。如果計劃使用 Silverlight 4 而不是 Silverlight 3，則必須假定用戶愿意并且能夠在計算機上安裝 Silverlight 的更新版本。

在 JavaScript 和 Silverlight 之間做出選擇時要考慮的最后一點與開發人員工作效率相關。在這一方面，Silverlight 開發明顯更勝一籌。這是因為您可以在 Visual Studio 2010 中工作并使用 C# 或 Visual Basic 編寫代碼。調用 .NET Framework 和客戶端對象模型中的方法時，您可以體驗編譯時類型檢查和 IntelliSense 的所有好處。還可以創建服務引用，從而大大簡化針對 Web 服務（如 ListData.svc）進行編程。

在 Visual Studio 2010 中對 JavaScript 進行編程的體驗與對 Silverlight 應用程序進行編程的體驗完全不同。沒有編譯時類型檢查，針對客戶端對象模型進行編程時也沒有任何 IntelliSense。此外，還需要掌握 JavaScript 和 ASP.NET AJAX 的高級編程技能，才能調用 Web 服務（如 ListData.svc）或者在更新 UI 中的內容之前從回調方法執行所需的線程切換。如果您剛剛開始學習編寫客戶端代碼，則與使用 JavaScript 編寫代碼相比，使用 Silverlight 開發是更好的選擇。

結論

本文討論了 SharePoint 2010 開發中的主要設計決定。您了解了為什么以及什么時候應該面向沙盒，以及什么時候應該創建需要服務器場級部署的 SharePoint 解決方案。您還了解了決定使用 Web 部件、網站頁面和應用程序構建自定義 UI 時要考慮的問題。

本文還討論了使用服務器端對象模型和客戶端對象模型的不同應用場景。您可以看出這實際上取決于特定應用場景的細節以及應用場景是否需要客戶端代碼。您還了解了，針對 SharePoint 對象進行編程和查詢列表時，服務器端代碼和客戶端代碼各自的特定優勢。有一點很明顯，那就是 SharePoint 開發人員現在編寫的客戶端代碼比過去多很多。

其他資源

有關詳細信息，請參閱以下資源：

• 使用 SharePoint Foundation 服務器端對象模型

• 使用 SharePoint Foundation 2010 托管客戶端對象模型

• 解決方案概述

• ECMAScript 類庫

• Visual Studio 2010 中的 SharePoint 2010 開發工具入門

• SharePoint 開發中心

• SharePoint 2010 客戶端對象模型資源中心（該鏈接可能指向英文頁面）

• Microsoft SharePoint 2010 SDK

• Microsoft SharePoint 團隊博客

關于作者

Ted Pattison?是一位作家兼講師，同時也是專門從事 SharePoint 技術培訓的?Critical Path Training（該鏈接可能指向英文頁面）公司的共同創始人。作為 Microsoft SharePoint 最有價值的專家 (MVP)，Ted 經常與 Microsoft Developer Platform Evangelism 小組合作，以便在產品生命周期的 Alpha 和 Beta 階段及早進行研究并為開發人員創作 SharePoint 培訓材料。Ted 還是?Inside Microsoft SharePoint 2010（該鏈接可能指向英文頁面）?一書的合著者。

總結

以上是生活随笔為你收集整理的了解 SharePoint 2010 开发中的关键点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。