我们发现 CRM 2011 的 Linq 严重损坏 - 它似乎在没有对其执行任何 QA 的情况下进入。提供程序损坏程度的指标是 .Where(x => x== "b") 之类的查询有效，但此 .Where(x => "b" == x) 可能不取决于某些先前的条件，例如 a加入声明。实际上，我不得不重写查询提供程序的部分内容，并且通过我整理的废话获得了更好的运气。
但是这不能继续下去，还有其他问题，而且我没有为 MS 工作获得报酬，所以我正在寻找替代方案。这两个出现了 QueryExpression 和 FetchXml，详见此处：http://msdn.microsoft.com/en-us/library/gg334607.aspx
谁能给我一个诚实的、真实的生活中使用 QueryExpression 与 FetchXml 的利弊？我想知道它们在性能、开发速度、稳健性和灵活性方面的比较。
【问题讨论】：
标签： linq dynamics-crm-2011 fetchxml query-expressions
我主张支持 FetchXML，因为我可以在我的 JavaScript 或 C# 代码中使用它，这与 LINQ 或 QueryExpression 不同...因此需要学习和维护的东西少了。至于诸如 Intellisense 之类的东西，有一个很棒的工具可以插入 XrmToolbox，名为FetchXML Builder，它在设计复杂查询方面比使用 Advanced Find 所看到的要复杂得多。我现在已经为一个 CRM Online 客户端使用它一个月了，它与在这个环境中可以使用的 SQL 一样接近。它还可以为我生成 QueryExpression 代码。我已将此工具交给我的业务分析师，他们将使用它为仪表板制作复杂的数据集——这对客户来说是一个巨大的胜利。
我很遗憾无法检测到早期绑定的错误，但我很享受
【讨论】：
一个客户特别要求我使用查询表达式模型，所以为了让我的生活更轻松，我求助于向 IOrganizationService 添加了很多扩展方法。示例包括：
public static List<T> GetEntities<T>(
this IOrganizationService service,
params object[] columnNameAndValuePairs
) where T : Entity
它将params object[]和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 限制陷阱。
【讨论】：
为了在 Anwar 专注于 LINQ 与 FetchXml 的出色答案的基础上再接再厉，我将添加我从不使用QueryExpression。 Why?
LINQ：查询是使用标准语言构建的，但在内部使用 QueryExpression 所以仅限于 QueryExpression 的功能。
QueryExpression：查询构建为对象模型。支持所有 FetchXML 中的功能，聚合和分组除外。
所以它的查询能力比FetchXml 更差没有高级查找代码生成，它提供与 LINQ 提供程序相同的功能，同时提供完全非标准的查询接口（与 LINQ 不同） .
至于 LINQ（非）功能，LINQ 提供程序的局限性很明显，我认为相当不错，documented。例如，您的.Where(x => "b" == x) sn-p 违反了where 子句限制：
where：子句左边必须是属性名，右边 子句的边必须是一个值。您不能将左侧设置为 持续的。子句两边不能是常数。
不为 Microsoft 辩护：他们需要在 LINQ 提供程序（阅读：直接到 SQL 提供程序）上投入大量工作，然后才能使 LINQ 提供程序变得专业等级，但是嘿，至少他们有一个很好的免责声明。
【讨论】：
QueryExpression。我必须补充一点，这些是微软的话，不是我的（见上面的链接），所以我不能更正他们的文档。
SOAPException。互联网上充斥着对此的抱怨。
在我看来，我通常会根据需求选择 Linq 或 FetchXml。
对于 Linq：在早期绑定的情况下，我喜欢使用 Linq，因为它是强类型的，并且对开发速度有很大帮助，但正如您上面所说，它有其缺点。
对于 FetchXML：我真的很喜欢使用这个神奇的语句：
EntityCollection result = _serviceProxy.RetrieveMultiple(new FetchExpression(fetch2));
foreach (var c in result.Entities)
{
System.Console.WriteLine(c.Attributes["name"]);
}
为什么？因为除了 aggregation 和 grouping 之外，它与使用 QueryExpression 非常相似。 我讨厌 FetxhXML 的唯一一点是它很难构建，不像 Linq。
为了构建 FetchXML 查询，我必须打开 Advanced-Find 然后添加列然后输入我的条件等等，最后我下载它并将它复制到我的代码中，等等。
最后，FetchXML 在其他方法中限制最少。
关于我尝试在 Linq 和 FetchXML 之间使用 StopWatch 对同一查询进行基准测试的性能，结果是 FetchXML 比 Linq 快。
【讨论】：