IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Dotnet Discussion :

Linq to entity


Sujet :

Dotnet

  1. #1
    Membre chevronné
    Inscrit en
    Octobre 2005
    Messages
    400
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 400
    Par défaut Linq to entity
    Bonjour

    J'aimerais avoir des retours sur l'utilisation de linq to entity. Mon objectif est de pouvoir dissocier la structure de ma base de données, de la structure de mes objets.

    Linq to entity semble fait pour cela. Sur les différents forums/labs/articles du net, tout semble tout beau, tout joli, mais en pratique je m'aperçois qu'il est vraiment difficile de dissocier la structure de ses objets de transports de la structure de la base de données.

    Par exemple, je n'arrive pas à mapper deux fois une même table.
    Autre exemple, je ne contrôle pas toutes les requêtes générées par le framework, et parfois, elles sont vraiment mal foutu...

    Je pourrais citer d'autre exemple, mais là n'est pas le but. Peut-être c'est moi qui l'utilise mal ?

    J'aimerais avoir des retours d'expérience (même si c'est encore tôt) sur l'utilisation du framework, peut être la comparer à un ORM style Nhibernate...

    Merci

  2. #2
    Membre chevronné
    Inscrit en
    Octobre 2005
    Messages
    400
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 400
    Par défaut
    J'ai juste l'impression que tout le monde parle de l'entity framework, tout le monde dit que c'est génial, mais personne l'utilise...

  3. #3
    Rédacteur
    Avatar de SaumonAgile
    Homme Profil pro
    Team leader
    Inscrit en
    Avril 2007
    Messages
    4 028
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Team leader
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2007
    Messages : 4 028
    Par défaut
    Pourquoi mapper deux fois la même table ? J'ai du mal à voir un cas où c'est nécessaire.
    Besoin d'un MessageBox amélioré ? InformationBox pour .NET 1.1, 2.0, 3.0, 3.5, 4.0 sous license Apache 2.0.

    Bonnes pratiques pour les accès aux données
    Débogage efficace en .NET
    LINQ to Objects : l'envers du décor

    Mon profil LinkedIn - MCT - MCPD WinForms - MCTS Applications Distribuées - MCTS WCF - MCTS WCF 4.0 - MCTS SQL Server 2008, Database Development - Mon blog - Twitter

  4. #4
    Membre chevronné
    Inscrit en
    Octobre 2005
    Messages
    400
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 400
    Par défaut
    J'ai une table Patient qui contient une vingtaine de propriétés.

    Je veux deux classes qui me gère cette table (PatientSimple et Patient). La classe PatientSimple n'aura que les propriétés Id, nom, prénom, date de naissance. Je souhaite utiliser cette classe pour de l'affichage uniquement, et je souhaite utilisé la classe Patient pour mes actions métier.

    Je ne veux pas générer une requête SQL qui retourne tous mes champs juste pour de l'affichage.

  5. #5
    Rédacteur
    Avatar de SaumonAgile
    Homme Profil pro
    Team leader
    Inscrit en
    Avril 2007
    Messages
    4 028
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Team leader
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2007
    Messages : 4 028
    Par défaut
    Deux réponses non exclusives :
    - Utiliser une relation d'héritage entre le client et le client simple.
    - Utiliser une requête Entity SQL pour récupérer les données nécessaires à l'affichage pour ne pas remonter toutes les infos et pour ne pas passer par l'étape de transformation en objet (Entity).
    Besoin d'un MessageBox amélioré ? InformationBox pour .NET 1.1, 2.0, 3.0, 3.5, 4.0 sous license Apache 2.0.

    Bonnes pratiques pour les accès aux données
    Débogage efficace en .NET
    LINQ to Objects : l'envers du décor

    Mon profil LinkedIn - MCT - MCPD WinForms - MCTS Applications Distribuées - MCTS WCF - MCTS WCF 4.0 - MCTS SQL Server 2008, Database Development - Mon blog - Twitter

  6. #6
    Membre chevronné
    Inscrit en
    Octobre 2005
    Messages
    400
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 400
    Par défaut
    La notion d'héritage --> c'est ce qu'on trouve sur le Net. Théoriquement tout est bien, mais en pratique c'est pas ça. En faite ça ne fonctionne pas exactement comme on se l'imagine. On peut intégrer la notion d'héritage de deux façons :
    - soit en conditionnant sur une colonne de la table (ex : J'ai une table 'Utilisateur' avec une colonne 'Type' qui peut prendre les valeurs 'Medecin', 'Patient', 'Administrateur', alors je peux créée une entité 'Person' et trois 'sous-entité' Medecin, Patient, Administrateur en précisant une condition sur la colonne Type --> pour l'entité Medecin, uniquement les personnes de type 'Medecin'...., ça ne me vas pas car j'ai pas de colonne qui peuvent me servir de condition...
    - soit en définissant la classe mère en tant qu'abstraite, le problème --> on ne peut plus requêter sur un PatientSimple...

    Ecrire une requête --> On perd l'interêt de linq to Entity. Si on fait une requête en chaîne de caractères, la requête n'est plus compilé donc pas vérifié, si on fait une requête avec typage anonyme, la requête envoyé à la base recherche tous les champs, elle sera du type 'Select nom, prenom from (Select * from Patient)'

  7. #7
    Rédacteur
    Avatar de SaumonAgile
    Homme Profil pro
    Team leader
    Inscrit en
    Avril 2007
    Messages
    4 028
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Team leader
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2007
    Messages : 4 028
    Par défaut
    Ben alors crée plusieurs modèles, ce n'est pas interdit.
    Besoin d'un MessageBox amélioré ? InformationBox pour .NET 1.1, 2.0, 3.0, 3.5, 4.0 sous license Apache 2.0.

    Bonnes pratiques pour les accès aux données
    Débogage efficace en .NET
    LINQ to Objects : l'envers du décor

    Mon profil LinkedIn - MCT - MCPD WinForms - MCTS Applications Distribuées - MCTS WCF - MCTS WCF 4.0 - MCTS SQL Server 2008, Database Development - Mon blog - Twitter

  8. #8
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Par défaut
    Citation Envoyé par oyigit Voir le message
    si on fait une requête avec typage anonyme, la requête envoyé à la base recherche tous les champs, elle sera du type 'Select nom, prenom from (Select * from Patient)'
    Et alors, en quoi est-ce un problème ? Seuls les champs nom et prénom seront transmis par le SGBD... ça ne coute pas plus cher en ressources que de faire directement "SELECT nom, prenom FROM Patient". Le seul inconvénient qu'il peut y avoir, c'est que même s'il y a un index sur (nom, prenom), le SGBD ira taper dans la table au lieu de prendre directement les données dans l'index...

  9. #9
    Membre chevronné
    Inscrit en
    Octobre 2005
    Messages
    400
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 400
    Par défaut
    Effectivement, on peut créé plusieurs modèle, ça fonctionne, assurèment ce n'est pas interdit, mais je trouve pas ça très propre. D'ailleurs j'ai pas envie de créé autant de modèle que je souhaite faire de sous type d'une entité, franchement c'est moyen, et niveau maintenance, c'est pas terrible non plus, je ne souhaite pas mettre à jour X modèle lors de changement de la base (surtout que la mise à jour avec VS fait un peu n'importe quoi).

    Bien entendu, à un moment ou à un autre, je devrais faire appel aux types anonymes, avec des requêtes custom, mais ça doit rester exceptionnel. Là, dans mon cas, je travaille sur un type précis, je souhaite garder le typage fort de mes données, au moins pour mes objets de transport les plus utilisés. Si je commence à implémenter des types anonymes pour mes objets les plus utilisé, alors à terme, la gestion des mes données, mes classes... va devenir un bordel. C'est un projet à long terme, avec une équipe de plusieurs développeur, il faut vraiment que les couches de base encadre le développement.

  10. #10
    Membre chevronné
    Inscrit en
    Octobre 2005
    Messages
    400
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 400
    Par défaut
    Et alors, en quoi est-ce un problème ? Seuls les champs nom et prénom seront transmis par le SGBD... ça ne coute pas plus cher en ressources que de faire directement "SELECT nom, prenom FROM Patient". Le seul inconvénient qu'il peut y avoir, c'est que même s'il y a un index sur (nom, prenom), le SGBD ira taper dans la table au lieu de prendre directement les données dans l'index...
    Alors effectivement dans ce cas, ça ne coûite pas plus cher dans ce cas, mais lorsqu'on y ajoute une jointure, ça devient plus compliqué. Je n'ai pas envie de faire une jointure sur l'ensemble des mes données...

Discussions similaires

  1. LINQ To Entity
    Par lutecefalco dans le forum Général Dotnet
    Réponses: 15
    Dernier message: 24/06/2008, 16h06
  2. Linq to Entities disponible dans C# Express ?
    Par rdh123 dans le forum Visual Studio
    Réponses: 1
    Dernier message: 15/06/2008, 12h43
  3. Linq to entities très bridé sur de gros projets !
    Par gillou.95 dans le forum Accès aux données
    Réponses: 7
    Dernier message: 15/05/2008, 16h02
  4. [Migration] linq to sql => linq to entities
    Par anthyme dans le forum Accès aux données
    Réponses: 1
    Dernier message: 25/04/2008, 18h48
  5. Orcas - Linq to Entities
    Par elnfrancois dans le forum Accès aux données
    Réponses: 2
    Dernier message: 31/08/2007, 10h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo