QueryExpression против FetchXml CRM2011 - PullRequest
Новая
       35

QueryExpression против FetchXml CRM2011

6 голосов
/ 07 февраля 2012

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

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

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

Ответы [ 4 ]

11 голосов
/ 08 февраля 2012

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

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

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

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

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

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

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

10 голосов
/ 07 февраля 2012

По-моему, я обычно выбираю 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.

6 голосов
/ 08 февраля 2012

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

2 голосов
/ 17 октября 2015

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

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

...