QueryExpression и CRM2011 FetchXml

мы узнали, что Linq для CRM 2011 ужасно сломан - похоже, он вошел без какого-либо QA, выполненного на нем. Индикатор, как сломана поставщик запрос .Где (x => x== "b") работает, но это .Где (x = > " b " = = x) может не зависеть от некоторых предыдущих условий, таких как оператор join. Мне действительно пришлось переписать части поставщика запросов и мне больше повезло с дерьмом,которое я собрал.

однако это не может продолжаться, есть еще другие проблемы, и мне не платят за работу в MS, поэтому я ищу альтернативы. Эти 2 придумали QueryExpression & FetchXml, как описано здесь:http://msdn.microsoft.com/en-us/library/gg334607.aspx

может ли кто-нибудь дать мне честные, реальные плюсы и минусы использования QueryExpression против FetchXml? Я хотел бы знать, как они сравниваются с точки зрения производительности, скорости развития, надежности и гибкости.

6
dynamics-crm-2011 fetchxml linq query-expressions

4 ответов

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

наконец, FetchXML имеет наименьшие ограничения среди других.

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

10

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

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

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

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

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

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

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

11

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

public static List<T> GetEntities<T>(
    this IOrganizationService service, 
    params object[] columnNameAndValuePairs
) where T : Entity

который преобразует объект params [] и тип сущности 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, в которые легко попасть.

6

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

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

2