QueryExpression и FetchXml CRM2011

На мой взгляд, я обычно выбираю 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 имеет наименьшие ограничения среди других.

Что касается производительности, которую я пытался сравнить между Linq и FetchXML для одного и того же запроса с помощью StopWatch, в результате FetchXML оказался быстрее, чем Linq.

В дополнение к отличному ответу Анвара, посвященному LINQ и FetchXml, я добавлю, что никогда не использую QueryExpression. Зачем?

LINQ: запросы строятся с использованием стандартного языка, но внутри используется QueryExpression, поэтому они ограничены функциями QueryExpression.

QueryExpression: запросы создаются как объектная модель. Поддерживает все функции FetchXML, кроме агрегатов и группировки.

Таким образом, он хуже с точки зрения мощности запросов, чем FetchXml без генерации кода расширенного поиска, и предлагает те же функции, что и поставщик LINQ, предлагая при этом совершенно нестандартный интерфейс запросов (в отличие от LINQ).

Что касается (не)функциональности LINQ, ограничения поставщика LINQ очевидны, и я думаю, достаточно хорошо, задокументировано. Ваш фрагмент .Where(x => "b" == x), например, нарушает ограничение пункта where:

где: левая часть предложения должна быть именем атрибута, а правая часть предложения должна быть значением. Вы не можете установить левую часть константой. Обе части предложения не могут быть константами.

Не защищая Microsoft: им нужно проделать много работы над провайдером LINQ (читай: провайдером прямого доступа к SQL), прежде чем провайдер LINQ станет профессиональным, но эй, по крайней мере, у них есть большой отказ от ответственности.

Клиент специально попросил меня использовать модель Query Expression, поэтому, чтобы облегчить себе жизнь, я прибегал к добавлению множества методов расширения в 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, в которые легко попасть.

Я бы выступал за FetchXML, потому что я могу использовать его в своем коде JavaScript или C#, в отличие от LINQ или QueryExpression... поэтому на одну вещь меньше, которую нужно изучать и поддерживать. Что касается таких вещей, как Intellisense, есть отличный инструмент, который подключается к XrmToolbox и называется FetchXML Builder. разработка сложных запросов, чем вы когда-либо увидите с помощью расширенного поиска. Я использую его уже месяц для клиента CRM Online, и он настолько близок к использованию SQL, насколько это возможно в этой среде. Он также может генерировать для меня код QueryExpression. Я передал этот инструмент своим бизнес-аналитикам, и они собираются использовать его для создания сложных наборов данных для информационной панели — большая победа для клиентов.

Я сожалею о потере обнаружения ошибок при раннем связывании, но мне нравится