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

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...:(

Pourquoi mapper deux fois la même table ? J'ai du mal à voir un cas où c'est nécessaire.

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.

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).

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)'

Ben alors crée plusieurs modèles, ce n'est pas interdit. ;)

Citation:

---

Envoyé par oyigit

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...

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.

Citation:

---

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...