none
Entity Framework, accès base asynchrone et contruction des requêtes LINQ RRS feed

  • Question

  • Bonjour,

    Ma question a peut être été posé 100 fois, le problème c'est que je ne sais pas comment organiser ma recherche pour trouver la réponse.

    Voilà, J'utilise actuellement Entity Framework dans ma formation et j'aurais des questions sur son fonctionnement :
    Lorsque je fais monContext.MonEntités, j'obtiens l'intégralité de la table, un équivalent de select * from MonEntité (voir pire vu que j'obtiens aussi la collection des occurences d'autres tables référençant la clé primaire de ma table MonEntités

    Ma première question du coup c'est la suivante :

    Est ce que lorsque je fais

    var maCollection = from entite in context.MonEntites
                       where entite.Valeur == 1
                       select entite

    Est ce que le context a déjà récupéré l'intégralité de la table pour ensuite faire son filtre sur le serveur d'application ou bien est ce que la construction de la requête sql dépend de la requête linq faite sur le contexte ?

    Je ne sais pas si je suis clair... Et j'ai a même question concernant les requêtes lambda de type context.MonEntites.where(ent=>ent.Valeur == 1).

    Ensuite, si le filtre se fait après, ça veut donc dire qu'il prend systématiquement l'intégralité de la table... Comment l'en empêcher ? En redéfinissant un autre type de collection dans l'entity ?

    J'espère avoir été clair, que ma question n'était pas trop stupide et qu'elle n'a pas été posé 150 fois (même si à mon avis elle a été posé bien plus souvent que ça :-) )

    J'aurais d'autres questions ensuite (dans le même genre, c'est à propos de la façon dont sont chargés les Entités en relation avec l'entité que je consulte)


    Merci !

    samedi 29 juin 2013 09:20

Réponses

  • Bonjour,

    Est ce que le context a déjà récupéré l'intégralité de la table pour ensuite faire son filtre sur le serveur d'application ou bien est ce que la construction de la requête sql dépend de la requête linq faite sur le contexte ?
    Non. Que vous utilisiez le mot clé C# Linq ou les lambdas expressions, la requête sera construite et exécutée au moment ou vous allez la parcourir (via un foreach, ToArray(), Single(),...).

    Parcontre, une fois que vous avez exécuté votre requête (via un ToArray() par exemple), et si continuez à utiliser les expressions lambda sur le résultat de la requête (ou les mots clé C# de Linq), vous allez requêter "en mémoire" sur vos objets, c'est à dire que vous n'effectuerait pas de requête à la base de données.

    Est-ce plus clair pour vous ?

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0

    • Marqué comme réponse Aurel Bera lundi 1 juillet 2013 07:23
    dimanche 30 juin 2013 22:48
    Modérateur

Toutes les réponses

  • Bonjour,

    Est ce que le context a déjà récupéré l'intégralité de la table pour ensuite faire son filtre sur le serveur d'application ou bien est ce que la construction de la requête sql dépend de la requête linq faite sur le contexte ?
    Non. Que vous utilisiez le mot clé C# Linq ou les lambdas expressions, la requête sera construite et exécutée au moment ou vous allez la parcourir (via un foreach, ToArray(), Single(),...).

    Parcontre, une fois que vous avez exécuté votre requête (via un ToArray() par exemple), et si continuez à utiliser les expressions lambda sur le résultat de la requête (ou les mots clé C# de Linq), vous allez requêter "en mémoire" sur vos objets, c'est à dire que vous n'effectuerait pas de requête à la base de données.

    Est-ce plus clair pour vous ?

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0

    • Marqué comme réponse Aurel Bera lundi 1 juillet 2013 07:23
    dimanche 30 juin 2013 22:48
    Modérateur
  • Bonjour, oui très clair merci !
    lundi 1 juillet 2013 05:46