QueryExpression vs. FetchXml CRM2011

Alwyn picture Alwyn · Feb 7, 2012 · Viewed 10.4k times · Source

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

Peter Majeed picture Peter Majeed · Feb 8, 2012

To build on Anwar's excellent answer focusing on LINQ vs. FetchXml, I'll add I never use QueryExpression. Why?

LINQ: Queries are built using standard language, but internally uses QueryExpression so is limited to the features of QueryExpression.

QueryExpression: Queries are built as an object model. Supports all the features in FetchXML except for aggregates and grouping.

So it's worse in querying power than FetchXml without the Advanced Find code generation, and it offers the same functionality as the LINQ provider while offering a completely non-standard querying interface (unlike LINQ).

As for LINQ (non)functionality, the limitations of the LINQ provider are clearly, and I think fairly well, documented. Your .Where(x => "b" == x) snippet, for instance, violates the where clause restriction:

where: The left side of the clause must be an attribute name and the right side of the clause must be a value. You cannot set the left side to a constant. Both the sides of the clause cannot be constants.

Not defending Microsoft: they need to put in a lot of work on the LINQ provider (read: direct-to-SQL provider) before the LINQ provider is professional grade, but hey, at least they've got a great disclaimer.