Question

We found out that Linq for CRM 2011 is horribly broken – it seems to have gotten in without any QA performed on it. An indicator as how badly broken the provider is a query like .Where(x => x== “b”) works but this .Where(x => “b” == x) might not depending on some preceding condition like a join statement. I have actually had to rewrite parts of the query provider and am enjoying better luck with the crap I put together.

However this can’t go on, there are still other issues and I’m not paid to to work for MS, so I’m looking at alternatives. These 2 came up QueryExpression & FetchXml as detailed here: http://msdn.microsoft.com/en-us/library/gg334607.aspx

Can anyone give me an honest, real life pros and cons of using QueryExpression vs. FetchXml? I would like to know how they compare in terms of performance, development speed, robustness and flexibility.

Answer 1

In my opinion, I usually go for Linq or FetchXml depending for the requirements.

For the Linq: In case for early-bound, I like using Linq because it’s strongly typed and It helps much for development speed, but as you stated above, it has its disadvantages.

For the FetchXML: I really love using this magic statement:

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

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

Why? Because it’s very similar of using the QueryExpression in addition of the aggregation and grouping.
The only thing I hate about FetxhXML is that it’s hard to build, unlike the Linq.

For building FetchXML queries, I have to open the Advanced-Find then add columns then put my criteria and so on, finally I download it and copy it into my code, and so on.

Finally, the FetchXML has the least limitations among the others.

Regarding the performance I’ve tried to benchmark between Linq and FetchXML for same query using StopWatch, the result was FetchXML is faster than the Linq.