Question

我们发现Linq for CRM 2011非常糟糕 - 它似乎没有在其上执行任何QA。一个指标显示提供者是多么糟糕的查询，如.Where（x =＆gt; x ==“b”）可以工作，但是.Where（x =＆gt;“b”== x）可能不依赖于某些先前的条件喜欢加入声明。我实际上不得不重写查询提供程序的部分内容，并且在我放在一起的废话中享受更好的运气。

然而，这还不能继续，还有其他问题，我没有为MS工作而付钱，所以我正在寻找其他选择。这两个问题出现在QueryExpression＆amp; FetchXml详见：http://msdn.microsoft.com/en-us/library/gg334607.aspx

任何人都可以给我一个使用QueryExpression与FetchXml的诚实，真实的利弊吗？我想知道他们在性能，开发速度，稳健性和灵活性方面的比较。

Answer 1

为了建立Anwar关于LINQ vs. FetchXml的优秀答案，我将添加 never 使用QueryExpression。 Why？

LINQ ：查询是使用标准语言构建的，但在内部使用   QueryExpression因此仅限于QueryExpression的功能。

QueryExpression ：查询构建为对象模型。支持所有   FetchXML中的功能，除了聚合和分组。

因此，在没有高级查找代码生成的情况下查询功率比FetchXml 更糟糕，它提供与LINQ提供程序相同的功能，同时提供完全非标准的查询接口（不同于LINQ）。

对于LINQ（非）功能，LINQ提供程序的局限性很明显，我认为相当不错，documented。例如，您的.Where(x => "b" == x)代码段违反了where条款限制：

其中：子句的左侧必须是属性名称和右侧该条款的一面必须是一个值。您不能将左侧设置为a 不变。该子句的两个边都不能是常量。

不为Microsoft辩护：他们需要在LINQ提供商专业之前在LINQ提供商（读取：直接到SQL提供商）上进行很多工作等级，但嘿，至少他们有一个很好的免责声明。

Answer 2

在我看来，我通常会根据要求选择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查询，我必须打开Advanced-Find然后添加列然后放入我的标准等等，最后我下载并将其复制到我的代码中，依此类推。

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

关于性能我尝试使用 StopWatch 在Linq和FetchXML之间进行相同查询的基准测试，结果是FetchXML比Linq更快。

Answer 3

我被客户专门要求使用查询表达式模型，所以为了让我的生活更轻松，我已经向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限制陷阱。

Answer 4

我主张支持FetchXML，因为我可以在我的JavaScript或C＃代码中使用它，这与LINQ或QueryExpression不同...因此，学习和维护的内容少了一些。对于像Intellisense这样的东西，有一个很棒的工具可以插入XrmToolbox，称为FetchXML Builder，它在设计复杂查询方面要比使用高级查找更加复杂。我现在已经在CRM Online客户端上使用它一个月了，它就像在这种环境中使用SQL一样接近。它也可以为我生成QueryExpression代码。我已将此工具交给我的业务分析师，他们将使用它为该仪表板制作复杂的数据集 - 这对客户来说是一个巨大的胜利。

我确实感叹早期绑定失去了检测错误，但我喜欢

QueryExpression与FetchXml CRM2011

4 个答案: