Performances de Linq aux entités vs ESQL

entity-framework entity-sql linq-to-entities

Question

En utilisant Entity Framework, ESQL fonctionne-t-il mieux que Linq to Entities?

Je préférerais utiliser Linq to Entities (principalement à cause de la vérification de type fort), mais certains des autres membres de mon équipe citent les performances comme raison d'utiliser ESQL. Je voudrais avoir une idée complète des avantages / inconvénients d'utiliser l'une ou l'autre méthode.

Réponse acceptée

Les différences les plus évidentes sont les suivantes:

Linq to Entities est un code fortement typé comprenant une syntaxe de compréhension de requête agréable. Le fait que le «de» vienne avant le «sélecteur» permet à IntelliSense de vous aider.

Entity SQL utilise des requêtes traditionnelles basées sur des chaînes avec une syntaxe plus familière, semblable à celle de SQL, où l'instruction SELECT précède l'instruction FROM. Comme eSQL est basé sur des chaînes, les requêtes dynamiques peuvent être composées de manière traditionnelle au moment de l’exécution à l’aide de la manipulation des chaînes.

La différence clé la moins évidente est la suivante:

Linq to Entities vous permet de modifier la forme ou de "projeter" les résultats de votre requête dans la forme dont vous avez besoin avec la syntaxe «select new {...}». Les types anonymes, nouveaux dans C # 3.0, l’autorisent.

La projection n'est pas possible avec Entity SQL car vous devez toujours renvoyer un objet ObjectQuery <T>. Dans certains scénarios, il est possible d'utiliser ObjectQuery <object>, mais vous devez éviter le fait que .Select renvoie toujours ObjectQuery <DbDataRecord>. Voir le code ci-dessous ...

ObjectQuery<DbDataRecord> query = DynamicQuery(context,
        "Products",
        "it.ProductName = 'Chai'",
        "it.ProductName, it.QuantityPerUnit");

public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
    ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
    ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
    ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
    return result;
}

Il existe d'autres différences plus subtiles décrites par l'un des membres de l'équipe en détail ici et ici .


Réponse populaire

ESQL peut également générer des fichiers SQL particulièrement vicieux. Je devais suivre un problème avec une telle requête qui utilisait des classes héritées et j'ai découvert que ma petite ESQL de 4 lignes avait été traduite dans une déclaration SQL monster de 100 000 caractères.

Est-ce que la même chose avec Linq et le code compilé était beaucoup plus gérable, disons 20 lignes de SQL.

De plus, ce que d’autres personnes ont mentionné, Linq est très typé, bien qu’il soit très pénible de déboguer sans les fonctions d’édition et de poursuite.

UN D



Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow