QueryExpression與FetchXml CRM2011

我們發現，LINQ的2011年CRM是可怕的損壞 - 它似乎已經得到了在不對其執行任何QA。一個指標是如何嚴重破壞供應商是一個查詢像.Where（x => x ==「b」）的作品，但這個.Where（x =>「b」== x）可能不會取決於前面的條件，如a加入聲明。實際上我不得不重寫部分查詢提供程序，並且將我放在一起的廢話與我一起享受更好的運氣。QueryExpression與FetchXml CRM2011

然而，這不能再繼續下去，還有其他的問題，我不支付爲MS工作，所以我在尋找替代品。這2上前QueryExpression & FetchXml詳見這裏：http://msdn.microsoft.com/en-us/library/gg334607.aspx

誰能給我使用QueryExpression與FetchXml的誠實，現實生活中的利弊？我想知道他們在性能，開發速度，穩健性和靈活性方面的比較。

來源

2012-02-07 Alwyn

在我看來，我通常去的LINQ或FetchXml根據的要求。

對於LINQ的：如果早期綁定，我喜歡使用LINQ，因爲它是強類型的，它有助於多的發展速度，但你如上所述，它有它的缺點。

對於FetchXML：我真的很喜歡使用這種神奇的語句：

EntityCollection result = _serviceProxy.RetrieveMultiple(new FetchExpression(fetch2)); 

foreach (var c in result.Entities) 
{ 
    System.Console.WriteLine(c.Attributes["name"]); 
}

爲什麼？因爲使用QueryExpression除了聚合和分組非常相似。我唯一討厭FetxhXML的地方就是它很難構建，不像Linq。

爲建設FetchXML查詢，我要打開高級 - 查找然後添加列，然後把我的標準等，最後我下載它，並把它複製到我的代碼，等等。

最後，FetchXML在其他方面的限制最少。

關於性能，我嘗試使用StopWatch對Linq和FetchXML進行基準測試，結果是FetchXML比Linq快。

來源

2012-02-07 19:29:17 Anwar

安華，你爲什麼說這是一個神奇的聲明？看起來你仍然需要將結果反序列化爲不容易的對象。我喜歡直接從CRM Web應用程序下載fetchxml的想法。 – Alwyn 2012-02-07 19:35:21

因爲以前在2004年CRM我只好返回的XML加載到如下然後檢查每個節點等，其結果一個可怕的代碼。 – Anwar 2012-02-07 19:41:18

明白了謝謝:) – Alwyn 2012-02-07 21:47:03

要建立在安華的出色答卷重點LINQ與FetchXml，我會添加我從未使用QueryExpression。 Why？

LINQ：查詢使用的是內置標準的語言，但在內部使用 QueryExpression所以僅限於QueryExpression的特點。

QueryExpression：查詢被構建爲一個對象模型。除彙總和分組外，支持FetchXML中的所有功能。

所以它在查詢功率比FetchXml沒有高級查找代碼生成糟糕的是，它提供了相同的功能的LINQ提供程序，同時提供一個完全非標查詢界面（不像LINQ）。

至於LINQ（非）功能，在LINQ提供程序的限制是清楚的，我覺得還算不錯，documented。你.Where(x => "b" == x)片段，例如，違反了where條款限制：

其中：該條款的左側必須是一個屬性名稱和條款的權利方必須是一個值。您不能將左側設置爲常量。子句的兩邊不能是常量。

不是衛冕微軟：他們需要把很多在LINQ提供工作（讀：直接到SQL供應商）的LINQ提供程序之前是專業級的，但是，嘿，至少他們有一個偉大的免責聲明。

來源

2012-02-08 02:30:57

你提到QueryExpression支持FetchXML所有功能，但它不能做嵌套的聯接，它不能做多重連接，它不能做外連接時，它不能做多的條件加入。但是，所有這些都可以使用FetchXml。 – Abel 2012-04-20 12:42:37

@Abel：因爲我不使用'QueryExpression'，所以我會說一句。我必須補充說那些是微軟的話，不是我的（見上面的鏈接），所以我不能糾正他們的文檔。 – 2012-04-20 15:23:43

嗯，更確切地說，QueryExpression類本身支持它們，但是當您嘗試針對CrmService運行表達式時，它總是會以'SOAPException'失敗。互聯網充滿了對此的抱怨。 – Abel 2012-04-20 20:44:27

我被一個客戶特別要求使用查詢表達式模式，這樣才能使我的生活更輕鬆，我已經使出加入了大量的擴展方法IOrganizationService。實例包括：

public static List<T> GetEntities<T>(
    this IOrganizationService service, 
    params object[] columnNameAndValuePairs 
) where T : Entity

其中params對象[]和T實體類型轉換成查詢表達式，並自動將結果返回給實體列表。所以用它像這樣：

foreach(var c in service.GetEntities<Contact>("lastname", "Doe", "firstname", "Smith")) 
{ 
    ... 
}

我也用這一個也不少：

public static T GetFirstOrDefault<T>(
    this IOrganizationService service, 
    params object[] columnNameAndValuePairs 
) where T : Entity 

var c = service.GetFirstOrDefault<Contact>("owner", id);

這些類型的擴展方法使與查詢工作表達式輕鬆了很多，給你一個更LINQ沒有奇怪的linq限制陷阱，很容易陷入。

來源

2012-02-08 15:13:14 Daryl

很好。感謝分享！ – Eccountable 2015-10-17 19:36:47

@Eccountable，請查看單元測試框架中的DLaB.Xrm.Common庫以獲取更多示例：https：//github.com/daryllabar/XrmUnitTest – Daryl 2015-10-17 21:29:41

我會贊成FetchXML的主張，因爲我可以在我的JavaScript或C＃代碼中使用它，不像LINQ或QueryExpression ......因此，一個學習和維護少的事情。至於像智能感知的東西，有一個偉大的工具，插入XrmToolbox稱爲FetchXML Builder是設計複雜的查詢要複雜得多比你永遠不會看到使用高級查找。我現在已經爲CRM Online客戶端使用了一個月，並且儘可能使用SQL，因爲您可以在此環境中使用SQL。它也可以爲我生成QueryExpression代碼。我已經將這個工具交給了我的業務分析師，他們將使用它來爲儀表板創建複雜的數據集 - 這對客戶來說是一個巨大的勝利。

我感嘆的早期綁定檢測錯誤的損失，但我喜歡

來源

2015-10-17 18:24:31 Eccountable

QueryExpression與FetchXml CRM2011

回答

相關問題