Discussion :

[marcusien]

Bonjour,

Je me demandais quelle était la meilleure façon d'architecturer un projet où l'on utilise Entity Framework avec un nombre très important de tables (entre 500 et 1000) ?

Pensez-vous qu'un unique fichier edmx suffit ? n'est-ce pas difficilement maintenable ?
Pensez-vous qu'il faille segmenter en plusieurs edmx ? dans ce cas, comment pourrait-on gérer des interdépendances entre ces edmx ? (c'est-à-dire si une table d'un fichier edmx a besoin d'une table d'un autre edmx)
Autre ?

Merci d'avance pour votre aide

Laurent

[tomlev]

Déjà je suis pas convaincu qu'Entity Framework soit adapté pour un aussi grand nombre de tables ; mais bon, c'est juste une intuition, j'ai pas d'éléments concrets pour le justifier...

Ce qui est quasiment certain, c'est que si tu as un seul EDMX avec tes 500 tables, le designer va jamais s'en sortir... au mieux, ça va tellement ramer que ce sera inutilisable, au pire ça va péter avec une OutOfMemoryException. Par contre, tu pourrais envisager l'approche Code First, où il n'y a pas de modèle EDMX mais des mappings définis dans le code. A mon avis c'est une approche beaucoup plus souple et plus facile à maintenir.

Sinon, une autre approche serait de découper le modèle en domaines indépendants plus petits

[meziantou]

Le post de Matthieu Mezil intitulé Comment découper ses entités en plusieurs modèles devrait t'aider

Son Edm Designer
http://edmdesigner.codeplex.com/

Comme la dit Tomlev je ne suis pas sûr qu'EF soit la méthode la plus adaptée. Pour les gros modèles je pense que des outils comme CodeFluent Entities sont plus adaptés.

[marcusien]

@Tomlev : Oui effectivement pour le designer je pense qu'il pourrait difficilement supporter un trop grand nombre d'entités, c'est pour cela que l'on se posait la question de découper le modèle en plusieurs sous-modèles.

D'ailleurs j'ai trouvé quelque chose qui s'appelle Entity Designer qui, apparemment, permet de faire plusieurs diagrammes dans un même fichier edmx. Quelqu'un aurait-il testé ou entendu parlé ?
http://blogs.msdn.com/b/efdesign/arc...s-preview.aspx

Je me penche également sur Code First.

A ma boite on utilisait XPO de DevExpress qui ne posait pas tant de soucis, mais EF apporte des choses dont on aurait besoin.

Merci Meziantou, est-ce qu'au final, découper le modèle en plusieurs fichiers edmx ne risque pas d'apporter beaucoup de problèmes ? cela me parait assez périlleux

[Er3van]

On parle de 500 tables dans le même schéma ?
Si oui ça me surprend... c'est du bancaire ?
Si non il y a une découpe qui semble assez évidente...

Pour Entity Framework, outre le côté Designer, ça va dépendre aussi de l’entremêlement entre tes tables. Si elles sont toutes liées entres elles, ça risque d'être assez peu performant.

[marcusien]

C'est un projet qui n'est pas encore commencé, justement on essaie de voir quel ORM choisir. Evidemment il y a possibilité de découper, mais on se posait la question concernant les tables qui seraient communes entre plusieurs schémas, si cela ne posait pas de problème au niveau des requêtes et de la mise à jour des tables (en cas de modification d'une table, si on devait répercuter les changements dans chacun des fichiers de modélisation)

[tomlev]

On parle de 500 tables dans le même schéma ?
Si oui ça me surprend... c'est du bancaire ?

Dans mon premier boulot, j'ai bossé avec un progiciel de facturation pour la téléphonie mobile... Il y avait environ 1200 tables dans la DB
(toutes dans le même schéma bien sûr ; pour couronner le tout, la plupart des tables avaient des noms super explicites, genre MPSSVTAB, MPUSNTAB, MPULKNXV... ceux qui ont utilisé le progiciel en question devraient reconnaitre )


Donc oui, ça existe... et c'est probablement pas si rare dans des systèmes complexes

[marcusien]

Nous développons un progiciel pour la gestion de domaines viticoles, donc nous risquons d'avoir pas mal de centaines de tables effectivement.

J'aimerais maintenant avoir votre avis quel choix feriez-vous parmi les suivants ?

1. Entity Framework 4.1 en mode designer : plusieurs edmx découpés en fonction de schémas/modules
2. Entity Framework 4.1 avec Code First
3. Entity Developer (logiciel de gestion d'entités)
4. XPO de DevExpress
5. Autres...

En partant du fait que l'on aura une grosse volumétrie en termes de nombre de tables

[meziantou]

Entity Framework 4.1 en mode designer : plusieurs edmx découpés en fonction de schémas/modules

Je disais juste que c'était faisable. Après ca reste assez périlleux car il s'agit de bidouille.

Entity Framework 4.1 avec Code First

Faisable mais long étant donnée le nombre de tables.

Autres...

Je conseils toujours CodeFluent Entities qui te permettra de gagner beaucoup de temps de dev