Nous avons découvert que Linq pour CRM 2011 est horriblement brisé - il semble avoir obtenu sans aucune qualité d'assurance qualité. Un indicateur comme à quel point le fournisseur est mal brisé est une requête comme .Où (x => x == "b") fonctionne mais ceci. Où (x => "b" == x) pourrait ne pas dépendre de certaines conditions précédentes comme une Rejoindre la déclaration. J'ai en fait avoir dû réécrire des parties du fournisseur de requêtes et profiter de la chance avec la merde que j'ai rassemblée.
Cependant, cela ne peut pas continuer, il y a toujours d'autres problèmes et je ne suis pas payé pour travailler pour MS, donc je regarde des alternatives. Ces 2 figurent QueryExpression & FetchXML comme détaillé ici: http://msdn.microsoft. com / fr-nous / bibliothèque / gg334607.aspx
Quelqu'un peut-il me donner un avantages et des inconvénients honnêtes, réels d'utiliser QueryExpression vs fetchxml? J'aimerais savoir comment ils se comparent en termes de performance, de vitesse de développement, de robustesse et de flexibilité.
4 Réponses :
À mon avis, je vais habituellement pour Linq ou FETCHXML en fonction des exigences.
pour le LINQ: En cas de fin, j'aime utiliser Linq car il est fortement tapé et cela aide beaucoup à la vitesse de développement, mais Comme vous l'avez dit ci-dessus, il a ses inconvénients.
pour le fetchxml: j'adore vraiment utiliser cette déclaration magique: pourquoi? Parce que c'est très similaire de l'utilisation de la QueryEyExpression en plus de l'agrégation pour la construction de requêtes FETCHXML, je dois ouvrir la recherche avancée, puis ajouter des colonnes puis mettre mes critères, puis sur, enfin, enfin. Je le télécharge et copiez-le dans mon code, et ainsi de suite. Enfin, le fetchxml a les moins limitations entre les autres. Concernant la performance que j'ai essayée de comparer entre LINQ et FETCHXML pour la même requête en utilisant chronomètre , le résultat était FETCHXML est plus rapide que le LINQ.
Anwar, pourquoi avez-vous dit que c'est une déclaration magique? On dirait que vous avez toujours besoin de désérialiser le résultat dans des objets qui ne sont pas faciles. J'aime l'idée de télécharger le FETCHXML à partir de l'application Web CRM directement.
Parce qu'auparavant dans CRM 2004, je devais charger le XML retourné dans un XMLDocument, puis vérifiez pour chaque nœud, etc., ce qui permet de trouver un code terrible.
Pour construire une excellente réponse d'Anwar se concentrant sur Linq vs. fetchxml, je vais ajouter i jamais utiliser linq : les requêtes sont construites à l'aide de la langue standard, mais utilise en interne
QueryEyXpression SO est limité aux caractéristiques de QueryExpression.
C'est donc pire dans la puissance de requête que comme pour la fonctionnalité LINQ (non), les limitations du fournisseur LINQ sont clairement, et je pense assez bien, Documenté . Votre où : le côté gauche de la clause doit être un nom d'attribut et la droite
côté de la clause doit être une valeur. Vous ne pouvez pas définir le côté gauche sur un
constant. Les deux côtés de la clause ne peuvent pas être des constantes.
Ne pas défendre Microsoft: ils ont besoin de mettre dans QueryExpression . Pourquoi ?
fetchxml sans la génération de code de recherche avancée, et offre la même fonctionnalité que le fournisseur LINQ tout en proposant une interrogation totalement non standard Interface (contrairement à LINQ).
.where (x => "b" == x) extrait, par exemple, enfreint le où restriction de la clause:
Vous mentionnez que QueryExpression prend en charge toutes les fonctionnalités de FETCHXML, mais il ne peut pas faire de jointures imbriquées, il ne peut pas faire de jointures multiples, il ne peut pas faire de jointures extérieures, il ne peut pas faire de jointures avec plusieurs conditions. Tous ceux-ci sont toutefois possibles avec FETCHXML.
@Abel: Je vais prendre votre mot sur cela, car je n'utilise pas QueryEyExpression . Je dois ajouter que ceux-ci sont les mots de Microsoft, pas la mienne (voir le lien ci-dessus), je ne peux donc pas corriger leur documentation.
Eh bien, plus précisément, la classe QueryExpression lui-même les soutient, mais lorsque vous essayez d'exécuter l'expression contre le crmservice, elle échouera toujours avec une exception SOAPException . Internet regorge de plaintes à ce sujet.
@Abel: Je vois - dommage! En espérant que Microsoft donne aux utilisateurs un accès complet à leurs propres données .
On m'a demandé spécifiquement d'utiliser le modèle d'expression de requête, afin de faciliter ma vie, j'ai eu recours à de nombreuses méthodes d'extension à iorganizationervice. Les exemples incluent:
public static T GetFirstOrDefault<T>(
this IOrganizationService service,
params object[] columnNameAndValuePairs
) where T : Entity
var c = service.GetFirstOrDefault<Contact>("owner", id);
@Eccountable, consultez la bibliothèque dlab.xrm.common dans le cadre de test unitaire pour plus d'exemples: Github.com/daryllabar / Xrmunittest
Je préconiserais en faveur de fetchxml parce que je peux l'utiliser dans mon code JavaScript ou C #, contrairement à Linq ou à QueryExpression ... donc une chose de moins à apprendre et à entretenir. Quant à des trucs comme IntelliSense, il existe un excellent outil qui se branche dans XRMToolbox appelé FETCHXML Builder qui est beaucoup plus sophistiqué dans concevoir des requêtes complexes que vous ne verrez jamais utiliser Recherche avancée. Je l'utilise maintenant pendant un mois pour un client CRM Online et il est aussi proche de l'utilisation de SQL comme vous pouvez entrer dans cet environnement. Il peut également générer un code QueryExpression pour moi. J'ai remis cet outil à mes analystes d'entreprise et ils vont en ville l'utilisant pour faire des ensembles de données sophistiqués pour le tableau de bord - une grande victoire pour les clients.
Je déplore la perte de détection d'erreurs avec une liaison anticipée, mais j'apprécie