使用 Microsoft Dynamics CRM 2015 開發的最佳作法
發行︰ 2016年11月
適用於： Dynamics CRM 2015
本主題說明自訂 Microsoft Dynamics CRM 2015 和 Microsoft Dynamics CRM Online 2015 更新 的最佳作法。
本主題內容
效能最佳作法
自訂最佳作法
安全性最佳作法
ISV 擴充性最佳作法
效能最佳作法
下列最佳作法可協助您撰寫提升效能的程式碼。
使用多個執行緒
新增執行緒支援至應用程式，分散跨多個 CPU 的工作。 此建議假設您在多處理器系統上執行程式碼。其他資訊：關於受管理執行緒的 NET Framework 進階開發指南文章。
允許系統建立 GUID
讓系統自動為您指派 GUID (ID)，而不自己手動建立。 此建議讓 Microsoft Dynamics 365 利用循序 GUID，提供較佳的 SQL 效能。 下列範例程式碼顯示如何呼叫 Create 方法，取得系統指派的 GUID。
// Instantiate an account object.Account account = new Account { Name = "Fourth Coffee" };
// Create an account record named Fourth Coffee and retrieve the GUID.accountId = serviceProxy.Create(account);
使用早期繫結類型
當程式碼必須在撰寫程式碼時不知道的實體和屬性上運作，使用 Entity 類別。 此外，如果您的自訂程式碼處理數千個實體記錄，使用 Entity 類別比早期繫結實體類型會導致效能稍微好一點。 不過，因為無法在編譯期間驗證實體和屬性名稱，此彈性有一個劣勢。 如果實體已在編碼時間定義，而且稍微的效能退化可接受，您應該使用早期繫結類型，可透過 CrmSvcUtil 工具產生。其他資訊：在程式碼中使用早期繫結實體類別
停用外掛程式
如果可能的話，執行您的應用程式之前，請停用已註冊的外掛程式。
建立更快速執行的外掛程式
一律撰寫需要最少時間執行其預定工作的外掛程式。 例如，Execute 方法經常在 Microsoft Dynamics 365 中處理。 如果您在該訊息上註冊外掛程式，則外掛程式可能會對系統造成重大的效能影響，因為每次 Execute 方法處理 (經常進行) 時就會執行它。
如果您想要註冊您的外掛程式以同步執行，建議您將它們設計在少於 10 秒完成作業。 最好讓外掛程式處理時間降至最低，以維護已連線至執行外掛程式之組織服務的用戶端應用程式互動功能。
限制您取得的資料
當您使用方法從伺服器擷取資料時，請擷取應用程式需求的最少資料量。 您可以透過指定資料行集合 (這是擷取的一組實體屬性) 這麼做。 例如，使用 RetrieveAllEntitiesRequest 訊息指定 EntityFilters 屬性的 EntityFilters.All 實體篩選，來擷取所有中繼資料，幾乎不是好主意。 相反地，如果限制實體篩選，或者使用下列其中一個訊息，可取得較佳的效能：RetrieveEntityRequest、RetrieveOptionSetRequest、RetrieveAttributeRequest 或 RetrieveRelationshipRequest。
限制串聯至相關實體的作業
當您使用 Update 方法或 UpdateRequest 訊息，不要設定記錄的 OwnerId 屬性，除非負責人已經實際變更。 當您設定此屬性時，變更通常串聯至相關實體，增加更新作業所需的時間。其他資訊：串聯行為
調整用戶端的 Proxy 設定 (僅限內部部署)
Proxy 伺服器坐落在用戶端應用程式 (例如網頁瀏覽器) 與實際目標伺服器之間。 在電腦位於 LAN 時，它使用 Proxy 伺服器連線至網際網路。 在此情況下，該 Proxy 伺服器會結合閘道伺服器與防火牆伺服器 (或成為其中一部分)。 該 Proxy 可以快取 Web 服務要求，並使用其快取資料來服務多個用戶端要求。 如果 Proxy 伺服器快取中沒有要求的資料，它使用自己的 IP 位址，將要求轉送至實際伺服器。 在這裡，Proxy 伺服器代表用戶端電腦作業。
雖然 Proxy 伺服器可當做快取伺服器，並協助快速載入網頁，但是如果不正確使用可能會降低效能。 通常，人員避免手動 Proxy 設定和使用自動 Proxy 設定。 此捷徑有助於 Proxy 伺服器負載平衡，但是，視設定指令碼的複雜度，當您使用自動 Proxy 設定時可能發生過長延誤。
安裝 Microsoft Dynamics 365 伺服器時，您可以會略過 Proxy 伺服器取得更佳的輸送量。 此伺服器提供近端網址，不需要 Proxy 即可到達。 您可以選取 [近端網址不使用 Proxy 伺服器]，並在例外清單中提供 Microsoft Dynamics 365 伺服器的完整網域名稱。 使用 Microsoft Dynamics CRM SDK 建立記錄時，這提供更佳的輸送量。
改善服務管道配置效能
使用 OrganizationServiceProxy 和 DiscoveryServiceProxy 服務 Proxy 類別服務。您可以建立連線至 Microsoft Dynamics 365 網站服務及驗證使用者。 不過，這些服務 Proxy 類別不正確使用有時會降低應用程式效能。 因此，如果您了解何時以及如何使用 SDK 的不同用戶端類別，通常會改善應用程式效能。
當您使用服務端點 (例如，使用組織 Web 服務) 建立 Windows Communication Foundation (WCF) 服務管道時，您的應用程式必須執行兩個耗時的作業：從端點下載中繼資料和使用者驗證。 若應用程式在每個應用程式工作階段中執行最少次數的這些作業，您可以改善效能。 在服務 Proxy 物件建立時，此處顯示的 OrganizationServiceProxy 建構函式執行這兩個作業。
OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, ClientCredentials deviceCredentials)
若應用程式使用此建構函式建立服務 Proxy 的執行個體，透過在應用程式工作階段期間使用此建構函式一次，以及快取傳回的參照以使用於應用程式中的不同程式碼路徑，您通常會改善效能。 請注意，傳回的服務參照並未具備執行緒安全，因此多執行緒應用程式需要為每個執行緒配置一個執行個體。 應用程式終止之前，必須也在服務 Proxy 物件上呼叫 Dispose，以釋放服務管道配置的資源。
使用下列類別方法，服務 Proxy 類別執行中繼資料下載和使用者驗證。
IServiceManagement<IOrganizationService> orgServiceManagement = ServiceConfigurationFactory.CreateManagement<IOrganizationService>(new Uri(organizationUrl))AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials)
CreateManagement<TService> 方法執行中繼資料下載，而 Authenticate 方法驗證使用者。 從這些方法傳回的物件是執行緒安全，而且可由您的應用程式靜態快取。 您可以使用這些物件，建構服務 Proxy 物件，使用其他可用的建構函式。
OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)
透過快取服務管理和驗證的認證物件，您的應用程式可以在每個應用程式工作階段中更有效建構服務 Proxy 物件超過一次。 如果您透過其中一個 EnableProxyTypes 方法，在 OrganizationServiceProxy 上啟用早期繫結類型，必須在從快取 IServiceManagement<TService> 物件建立的所有服務 Proxy 上執行相同作業。 如果您的應用程式使用中繼資料，建議其快取擷取的中繼資料並定期呼叫 RetrieveTimestampRequest 訊息決定是否必須重新整理快取。
此外，請監視您的 WCF 安全性權杖 (Token) 並在到期之前重新整理它，這樣就不會遺失權杖，而必須重新驗證。 若要檢查權杖，可以建立從 OrganizationServiceProxy 或 DiscoveryServiceProxy 類別繼承，以及實作商務邏輯檢查權杖的自訂類別。 或者將 Proxy 類別包裝在新類別中。 另一個技術是在每一次對 Web 服務呼叫之前，明確檢查權杖該標籤。 示範這些技術的範例程式碼可在 Helper 程式碼：ServerConnection 類別 主題中的 ManagedTokenDiscoveryServiceProxy、ManagedTokenOrganizationServiceProxy 和 AutoRefreshSecurityToken 類別找到。
自訂最佳作法
下列最佳作法協助您自訂及擴充 Microsoft Dynamics 365。
Microsoft Dynamics CRM Online 最佳作法
適用於解決方案建造商的 Microsoft Dynamics CRM Online 模式與原則白皮書下載特別提供關於使用 Microsoft Dynamics CRM Online 建立解決方案的指導。
使用自訂實體與屬性
使用這些技術，節省伺服器空間：
建立現有實體的自訂屬性，而不建立新實體。
將現有的實體重新命名，讓實體更有意義。
何時應該自訂實體？
自訂系統實體，例如商機實體，而非取代為新的自訂實體，以便在現有實體中使用許多內建功能。 例如，商機和案例實體有關聯客戶的查詢欄位。 客戶可以指客戶本身或連絡人。 您無法建立有相同查詢類型的自訂實體。 您可以變更系統實體顯示名稱，讓它對您的業務更有意義。
何時使用外掛程式與工作流程？
身為有興趣擴充或自訂 Microsoft Dynamics 365 的開發人員，您可以從多種方法選取進行工作。 除了將用戶端 JavaScript 程式碼新增至表單或新增自訂 ASP.NET 頁面之外，您還可以使用 Web 介面呼叫自訂工作流程活動，撰寫外掛程式或建立自訂工作流程。 如何決定何時使用外掛程式和使用工作流程？ 使用技術取決於您必須執行的工作，以及會製作自訂的作者。
例如，若要在核心平台作業之前或之後，以及從平台傳回作業結果之前，執行自訂程式碼，您必須使用同步外掛程式即時工作流程。 在此情況下，您無法使用非同步工作流程或非同步外掛程式，因為這些會排入佇列中，等待在核心作業完成執行後才執行。 因此，您無法預測它們何時執行。 若要新增自訂功能至 Microsoft Dynamics CRM Online，支援工作流程和外掛程式，但不支援自訂工作流程活動。
請在考量您的外掛程式或工作流程解決方案之部署、效能和維護議題後，評估這些技術並選取最符合您的業務目的使用的項目。
下列表格摘要外掛程式和工作流程的特性。
準則 |
外掛程式 |
工作流程 |
|---|---|---|
在核心平台作業前後執行 (建立、更新、刪除等) |
或在核心作業前後立即執行 (同步)。 也可以排入佇列中，等待在核心作業之後執行 (非同步)。 |
非同步工作流程會排入佇列中，等待在核心作業之後執行。 即時工作流程有類似於外掛程式的特性。 |
對伺服器的效能影響 |
同步的外掛程式會增加平台回應時間，因為它們是主要平台程序的一部分。 非同步外掛程式對伺服器回應時間有較小影響，因為程式碼在不同的處理序中執行。 |
非同步工作流程對伺服器回應時間有較小影響，因為程式碼在不同的處理序中執行。 即時工作流程有類似於沙箱化外掛程式的效能特性。 |
安全性限制 |
若要向平台註冊外掛程式，需要系統管理員或系統自訂員資訊安全角色和部署管理員群組的成員資格。 |
使用者可以在 Web 應用程式中透過互動方式建立工作流程。 不過，若要註冊自訂工作流程活動，部署的使用者必須擁有和註冊外掛程式所需相同的資訊安全角色。 |
Microsoft Dynamics 365 版本 (SKU) 支援 |
在沙箱中註冊，Microsoft Dynamics CRM Online 中支援。 合作夥伴託管的安裝中可支援 (由合作夥伴酌量採用)。 |
所有 Dynamics 365 部署都支援工作流程。 在 Microsoft Dynamics CRM Online 沙箱，以及內部部署/IFD 部署的沙箱內外，支援自訂工作流程活動。 |
處理時間長度 |
為同步或非同步執行註冊的外掛程式限制在兩分鐘的時間限制內完成其執行。 |
長或短時間的程序都能正常運作。 不過，工作流程中每個活動無法超過兩分鐘才完成。 |
Dynamics CRM for Outlook 用戶端離線時正常運作 |
支援線上和離線。 |
當離線時工作流程不執行。 |
處理和資料持續性 |
外掛程式執行，直到完成。 外掛程式必須撰寫為無狀態，也就是沒有記憶體內部資料持續。 |
非同步工作流程可以透過 SDK 或由使用者透過 Web 應用程式暫停、延後、取消和繼續。 在暫停或延期工作流程之前，狀態會自動儲存。 即時工作流程無法有任何等候狀態。 它們必須執行直到完成，就如同外掛程式。 |
模擬 |
外掛程式可以代表其他系統使用者執行資料作業。 |
非同步工作流程無法使用模擬，即時工作流程可以。 即時工作流程可以執行做為工作流程的負責人或做為呼叫使用者。 |
撰寫 |
軟體工程師或程式設計師可以撰寫外掛程式。 |
若有適當的權限，任何人，包括使用者、商務分析師或系統管理員都可以撰寫工作流程。 |
非同步外掛程式與工作流程之間影響對伺服器不會造成重大的效能影響。
哪種工作流程比較好？
從效能觀點，建立單一完整的工作流程比較好，或者有多個子工作流程然後在上層工作流程中呼叫它們比較好？ 子工作流程達成較小的輸送量，但是，如果您經常變更工作流程定義，它比較容易管理。 編譯負荷不是主要問題，因為工作流程只在發行時編譯。 不過，當它啟動每個工作流程執行個體時，Microsoft Dynamics 365 會造成負荷。 當擷取用於工作流程中的任何實體，以及兩個步驟的程序 (包括「工作流程擴充作業」和實際工作流程執行個體) 中啟動子工作流程時，會發生負荷。 因此，為取得最大輸送量，請使用單一完整的工作流程。
應該如何將自訂工作流程活動標記為已完成？
工作流程執行階段使用來從 Execute 方法的傳回值，將活動標示為「已完成」。 除非活動略過基底類別功能，否則您應使用 return base.Execute(executionContext)。 避免傳回 ActivityExecutionStatus.Closed。其他資訊：ActivityExecutionStatus 列舉
應該如何在自訂工作流程活中報告例外狀況？
您應該在程式碼中擲回 InvalidPlugInExecutionException。 此錯誤會顯示在工作流程執行個體表單。
您可以定義業務單位專屬的自訂實體嗎？
自訂實體有每個資訊安全角色的權限，但沒有每個業務單位的權限。 若要定義只有指定的業務單位看得見的自訂實體，您必須為每個業務單位建立不同資訊安全角色，並在適當角色中授與自訂實體的權限。
安全性最佳作法
依照這些指導方針來協助保護您的商務資料。
一般
保護您的 Microsoft Dynamics 365 實作的最佳作法包括：
為組織的 Microsoft Dynamics 365 實作建立核准的安全性資料方案。
當您設定應用程式集區，指派最低的必要權限。
要求所有使用者使用強式的帳戶密碼。 如需詳細資訊，請在 Windows 說明中搜尋「強式密碼」。
其他資訊：TechNet：Microsoft Dynamics CRM 的安全性考量
角色、權限和存取權限
使用 Microsoft Dynamics 365 安全性模型的最佳作法包括：
嚴格限制被指派系統管理員角色的人數。 不要移除此角色。
根據最低權限的安全性最佳作法建立角色，提供存取工作所需的最低商務資料量。 指派使用者其工作的適當角色。
以某些特定權限建立新的角色，如果使用者需要其他存取等級或權限，則將使用者新增至新角色。 使用者權利是使用者被指派所有角色的聯集。 不要授與只有一個或多個成員需要的原始角色權限。
適時使用共用來提供使用者個別物件的特定權限，而非特定類型的所有物件更廣大的權限。
使用團隊建立跨職務團隊，讓特定物件可以與團隊共用。
訓練有共用存取權限的使用者，共用所需的最少資訊。
避免權限升級
使用者可以採用受信任帳戶的權限，例如負責人或系統管理員權限時，發生權限升級攻擊。 一律在最低權限使用者帳戶下執行，並只指派所需的權限。 避免使用系統管理員或負責人帳戶執行程式碼。 如果攻擊成功，這會限制損壞程度。 在執行需要額外權限的工作時，請只在工作期間使用程序簽署或模擬。
伺服器端程式開發
為 Microsoft Dynamics 365 開發伺服器端程式碼的最佳作法包括：
除非使用 SDK，不論任何不要修改 Microsoft Dynamics 365 資料庫，因為這樣會略過 Microsoft Dynamics 365 安全性模型。
外掛程式是在系統管理員的內容中執行 - 您必須知道此程式碼可以存取登入使用者所無法存取的資訊。
針對工作流程組件和外掛程式，請避免建立需要長時間執行的程式碼。 重要的是，註冊同步執行的外掛程式碼應盡快傳回。
如果您在自己的資料儲存區中複寫 Microsoft Dynamics 365 資料，您將負責資料的安全性。 如果您使用外掛程式傳送資料，請務必註冊外掛程式在核心平台作業之後執行。 登入使用者的安全性權限檢查在核心平台作業時發生。
來自 Microsoft Dynamics 365 的資料可能對呈現不安全。 資料可能被插入不安全的 HTML 標籤。
遵循不直接透過 SQL Server Enterprise Manager 存取 Microsoft Dynamics 365 資料庫的要求。 略過 SDK 對您開啟 SQL 插入威脅。
對於網際網路對向部署，請記住，您解決方案的安全性取決於最弱的一環。 當您的應用程式在網際網路上公開之後，即開放給安全性威脅。
只使用造成防止緩衝區滿溢、例外狀況等的最佳安全性受管理程式碼的語言。
如需安全性的詳細資訊，請參閱下列主題：
用戶端程式開發
開發 Dynamics 365 Web 應用程式及 Microsoft Dynamics CRM for Outlook 自訂的最佳作法包括：
盡可能使用 Web 資源，而非需要伺服器端處理的頁面。 如果您的需要只能透過使用伺服器端處理達成，請遵循自訂網頁安裝在不同於 Microsoft Dynamics 365 的個別網站中之要求。 依據程式碼的信心程度，正確設定網站的信任等級。 這可減少來自跨網站指令碼的威脅與其他威脅。
為了改善安全性，請確定您的網站與 Microsoft Dynamics 365 使用不同帳戶執行。 此帳戶只應有最低存取權，而且沒有 Microsoft 資料庫的直接存取。 您可以使用不會到期的複雜密碼，因為使用者無法登入此帳戶，他們僅登入您的應用程式。
避免使用 ActiveX 控制項，因為它們有已知安全問題。
請注意用戶端指令碼限制。其他資訊：撰寫 Microsoft Dynamics CRM 2015 表單的程式碼
使用外掛程式套用商務邏輯，不論資料如何進行變更。
刪除記錄或套用敏感性變更時，例如新增使用者至資訊安全角色，一律使用確認對話方塊。 您可以對此使用 Xrm.Utility.confirmDialog。 這有助於防止點閱綁架或 UI 重新定址等技術，透過這些技術，惡意開發人員將您的頁面內嵌在看似無害的頁面，欺騙使用者執行可能洩露安全性的動作或在資料上執行不需要的動作。
網站安全性的最佳作法包括：
不使用匿名存取。
使用整合式 Windows 驗證、NTLM 或在 安全通訊端層 (SSL) 上使用基本驗證。
如果您的網站 Microsoft Dynamics 365 與位在不同電腦，使用 SSL 避免在網路上傳送未加密的資料。
如需詳細資訊，請參閱以下各項：
ISV 擴充性最佳作法
ISV 擴充性的其中一個重要原則為，您不應該假設，您的 ISV 解決方案是唯一安裝的軟體。 下列是應遵循的最佳作法清單。
使用 Microsoft Dynamics CRM Web 服務的最佳作法
您應該將 Microsoft Dynamics 365 Web 服務 URL 放入設定檔，例如，app.config 檔案，讓程式碼與 URL 變更隔離。 例如，在世界各地的三個 Microsoft Dynamics CRM Online 資料中心有不同 URL。
您應將外掛程式及自訂工作流程活動放在何處？
針對磁碟上外掛程式或自訂工作流程活動，請將組件放入 <installdir>\Server\bin\assembly 資料夾。
您應將自訂 Web 應用程式或網頁放在何處？
請參閱主題 從 ASPX 網頁或 IFRAME 實作單一登入。
在 Web 應用程式的網格檢視更新時，如何執行外掛程式？
在 RetrieveMultipleRequest 訊息要求上註冊外掛程式，而不要在註冊時指定任何實體類型。
您何時應該建立新網站？
當下列任一項適用時，請為您的程式碼建立新網站：
您的應用程式必須與 Microsoft Dynamics 365 應用程式繫結至不同網域、通訊協定或連接埠，或是必須在不同的應用程式集區中執行。
您的應用程式可以單獨存在和存取。 例如，入口網站做為伺服器 (使用 Web 服務) 與 Microsoft Dynamics 365 互動，應託管做為新網站。
您的應用程式一律使用 Active Directory 或整合式 Windows 驗證 (非 IFD)，而且跨網域指令碼不是問題。 例如，您的應用程式使用 Web 服務與後端互動，以及與 Microsoft Dynamics 365 表單互動。 IFRAME 裝載的頁面，包含在不與 Microsoft Dynamics 365 表單互動的 Microsoft Dynamics 365 應用程式，屬於此類別。
另請參閱
撰寫應用程式和伺服器擴充功能
設定位元旗標
撰寫 Microsoft Dynamics CRM 2015 表單的程式碼
撰寫可擴充商務程序的外掛程式
自訂工作流程活動 (工作流程組件)
© 2017 Microsoft. 著作權所有，並保留一切權利。 著作權