Discussion :

[gillou.95]

Bonjour tout le monde !

En vue de migrer une application qui utilise les DataSet vers des Entités (pour profiter du modèle objet et non relationnel), je suis en train de faire une analyse sur Linq to Entities.

Voilà mon problème :
Je dispose d'une plate-forme (solution) avec 120 projets. Cela parrait beaucoup, mais en fait il y a 36 modules éclatés en 3 couches classiques (IHM, Métier, DAL). Chaque module représente un traitement spécifique (gestion des clients, fournisseurs, facturation, commandes, compta,...etc).

Les 12 projets restants représentent 4 applications (éclatées aussi en 3 couches) de gestion qui utilise + ou - les modules précédents.

Actuellement, certains modules sont très basiques et propose des services de base qu'il devront être implémenté par les applications (ou d'autres modules).
Par exemple, je dispose d'un module appelé "Pièce commerciale" qui représente de façon abstraite un "Bon de livraison", une "Facture", ...etc.
Le module "Facture" utilise donc le module "Pièce commerciale" et ajoute des fonctionnalités spécifiques à la facturation.

Avec les DataSet, la solution était simple :
Dans le module Facture je crée un DataSet typé "Facture" que j'utilise dans celui-ci (Nom, Prénom, Réglement) et que je peux utiliser dans le module "Pièce Commerciale".
Dans le module Bon de livraison je crée un DataSet typé "BonLivraison" que j'utilise dans celui-ci (Nom, Prénom, DateLivraison) et que je peux utiliser dans le module "Pièce Commerciale".
...etc

Dans le module Pièce commerciale quand à lui utilise des DataSet de façon générique. C'est à dire il manipule uniquement des données commune au pièces commerciales par exemple pour accéder au nom : pièceCommercialeTable["Nom"] (où pièceCommercialeTable est déclaré comme DataTable et peux contenir une instance de BonLivraison ou de Facture).

Cette solution bien évidemment pose un problème de typage de code au niveau de la pièce commerciale mais permet de factoriser en masse du code !!

Avec linq to entities :
Le problème est simple, il n'est pas possible de créer une classe abstraite PièceCommerciale dans le module "Pièce commerciale" et de la faire hériter dans d'autres modules (projets) "BonLivraison" et "Facture".
En plus la classe abstraite doit avoir au moins une clé unique, et dans mon cas c'est la classe qui hérite qui indique la clé primaire...

Aussi, le principe d'éclater le mapping des entités en 3 fichiers (csdl, ssdl, msdl) est interessant, mais il n'est pas possible de prendre le ssdl et msdl automatiquement générés et de les inclure dans d'autres projets (dans la couche DAL).

Question : Savez s'il est possible de faire de l'héritage d'entité entre différents modèles sur différents projets ? Si c'est pas le cas, croyez vous qu'il faut que je crée mes propres entités à la main ?

Bref, j'ai l'impression que linq to entities est un bon O/R mapping, mais il loin d'être la solution pour de gros projets ! C'est dommage que l'on doit l'utiliser uniquement dans le cadre de petit projets avec un seul modèle...

Merci de vos lumières !

Cordialement

[anthyme]

ce que je peux en dire c que deja pour les fichier de mapping tu peux les inclure dans la dll au lieu de les mettre en output, moi je trouve cela plus pratique.

ensuite, a tu essayer de générer le mapping a partir de ta base ? il va peut etre comprendre tout seul qu'il y a de l'héritage (pas sur)

Dans les fait il y a l'héritage dans les entities, pas forcement avec des class abstraite mais rien ne t empêche de ne pas instancié la classe mere si tu n'en a pas envie.

[gillou.95]

Bonjour,

Merci pour ta réponse.
Je peux importer toutes les tables dans mon modèle (environ 160) sans problème. Je dois forcement éclater ce modèle dans diverses projet, car sinon ma plate-forme n'est point modulaire et je risque de livrer un executable de 50 Mo ! (Ceci étant dis ce n'est pas un problème de couper les 160 entités dans diverses modèles EDM).

Le seul hic, qui limite énormement l'utilisation de EDM, c'est qu'il est impossible de créer une entité d'un modèle EDM qui hérite d'une autre entité présente dans un autre modèle EDM qui se trouve dans un autre projet !
C'est même pire : si dans un même projet on a deux modèles EDM différents, il est alors impossible de faire de l'héritage entre ces deux modèles.

Ca fait de linq to entities un framework très bridé auquel il faut tout regrouper dans un seul et unique projet (aucune modularité dans ce cas).

En ce qui concerne les fichiers de mapping, je sais que l'on peut les importer dans une DLL (celle où se situe le modèle EDM et donc dans la couche métier). Mais en faisant ainsi on livre des mapping qui sont propres aux SGBD dans la couche métier !

La question que je me pose est : dois je faire mes propres entités à la main ?

Encore merci de vos lumières

Cordialement

[anthyme]

[QUOTE=gillou.95;3263986]Bonjour,

Merci pour ta réponse.
Je peux importer toutes les tables dans mon modèle (environ 160) sans problème. Je dois forcement éclater ce modèle dans diverses projet, car sinon ma plate-forme n'est point modulaire et je risque de livrer un executable de 50 Mo ! (Ceci étant dis ce n'est pas un problème de couper les 160 entités dans diverses modèles EDM).

hummm oui la modularité semble effectivement nécessaire ici

Le seul hic, qui limite énormement l'utilisation de EDM, c'est qu'il est impossible de créer une entité d'un modèle EDM qui hérite d'une autre entité présente dans un autre modèle EDM qui se trouve dans un autre projet !
C'est même pire : si dans un même projet on a deux modèles EDM différents, il est alors impossible de faire de l'héritage entre ces deux modèles.

oui ce qui te pose problème c'est le coté monolithique de la déclaration du mapping.
Et effectivement je ne pense pas que FE soit prévu pour que tu puisse faire communiquer tes edm ensemble chaque edm est ta couche de context d'accès aux données.

Ca fait de linq to entities un framework très bridé auquel il faut tout regrouper dans un seul et unique projet (aucune modularité dans ce cas).

Mais bon il faut pas oublier que ce n'est pas un logiciel fini et qu'il est en beta pendant encore de nombreux mois, il sont peut etre en train d'y penser et si tu as peur que cela ne soit pas le cas, tu devrais leur envoyer un ptit mail il te diront si il compte implementer quelque chose dans ce sens la ou peut etre une solution déjà existante

En ce qui concerne les fichiers de mapping, je sais que l'on peut les importer dans une DLL (celle où se situe le modèle EDM et donc dans la couche métier). Mais en faisant ainsi on livre des mapping qui sont propres aux SGBD dans la couche métier !

Avec l'ORM (probablement le plus utilisé) hibernate (et JPA) en java on définit les table via des attribut sur des classe java compilé, et cela depuis des années sans que cela ne pose de problème.
Tu ne vas pas t amuser a changer les noms de tes colonnes tous les jours ...

La question que je me pose est : dois je faire mes propres entités à la main ?

bin sinon tu peux essayer nhibernate si tu peux pas attendre la sortie final de linq to Entities. C'est un très bon ORM robuste performant et efficace.

[gillou.95]

Bonjour,

Merci pour ces précisions...
Encore quelques questions :

Est-ce que nHibernate gère comme les datacontext, l'unicité des instances des objets qui sont automatiquement généré ?
Est-ce que nHibernate gère les problèmes de tracking ?
Est-ce que avec nHibernate on doit créer son propre système de mise à jour des données en déconnecté ? (Même "problème" que sous linq to sql/entities)

Cordialement

[anthyme]

Est-ce que nHibernate gère comme les datacontext, l'unicité des instances des objets qui sont automatiquement généré ?

Oui

Est-ce que nHibernate gère les problèmes de tracking ?

Je ne connais pas ces problèmes

Est-ce que avec nHibernate on doit créer son propre système de mise à jour des données en déconnecté ? (Même "problème" que sous linq to sql/entities)

Je ne vois pas ce que tu veux dire exactement, par exemple dans le framework entities tu as la capacité d'attacher et de détacher les entités au context (même apres les avoir envoyer chez un client, serialisé dans un fichier, ...) avec les mise a jour appliqué au moment ou il est réataché.

[gillou.95]

Merci encore pour ces lumières...

En fait il me semble (j'ai du comprendre de travers) que sous Linq to Sql/entites si l'on détache un objet du datacontext, on réalise des modifications et que l'on rattache celui-ci dans un nouveau contexte, le .NET Framework n'est pas capable de déterminer les modifications de cette entités et la mide à jour est impossible... Me trompes-je ?

Je me pose aussi la questions suivante : Le gros problème de linq to sql/entities et qu'il faut explicitement marquer les entités à supprimer/ajouter.
Contrairement aux DataSet ou l'on diposait d'un attribut RowState...
On doit donc réaliser ce genre de "tracking" manuellement, ou alors proposer dans les couche métier explicitement des méthodes "AjouteFacture, SupprimeFacture, ModifieFactture,...etc".
Est-ce que dans nHibernate il existerait un tel "tracking" (le mot n'est pas très bien choisi) ?

Et encore merci d'éclairer ma lanterne !

Cordialement

[anthyme]

Merci encore pour ces lumières...

En fait il me semble (j'ai du comprendre de travers) que sous Linq to Sql/entites si l'on détache un objet du datacontext, on réalise des modifications et que l'on rattache celui-ci dans un nouveau contexte, le .NET Framework n'est pas capable de déterminer les modifications de cette entités et la mide à jour est impossible... Me trompes-je ?

Je crois sinon je ne vois pas vraiment l'interet !

Je me pose aussi la questions suivante : Le gros problème de linq to sql/entities et qu'il faut explicitement marquer les entités à supprimer/ajouter.
Contrairement aux DataSet ou l'on diposait d'un attribut RowState...
On doit donc réaliser ce genre de "tracking" manuellement, ou alors proposer dans les couche métier explicitement des méthodes "AjouteFacture, SupprimeFacture, ModifieFactture,...etc".
Est-ce que dans nHibernate il existerait un tel "tracking" (le mot n'est pas très bien choisi) ?

petite note : je suis totalement allergique aux dataset et je ne comprend pas forcement toutes les finesse de la chose
Sinon bin je pense que le fonctionnement est proche. si je me rappele bien (ca fait 1 an et demi que j ai fait du nhibernate) tu a un entity context manager avec des méthodes save et delete pour enregistrer ou supprimer des objet mais a vrai dire je ne vois pas vraiment comment on pourrait faire sans ...