Grande base de données est toujours quelque chose de spécial. Toute technologie a des avantages et des inconvénients lorsque vous travaillez avec une grande base de données.
Le problème que vous avez rencontré est probablement lié à la construction du modèle. Lorsque vous démarrez l'application et que vous utilisez EF pour la première fois, EF doit créer la description du modèle et la compiler. C'est l'opération la plus longue que vous pouvez trouver dans EF. La complexité de cette opération augmente avec le nombre d'entités dans le modèle. Une fois le modèle compilé, il est réutilisé pour toute la durée de vie de l'application (si vous redémarrez l'application ou déchargez le domaine d'application, le modèle doit être compilé à nouveau). Vous pouvez éviter cela en précompilant le modèle. C'est fait au moment du design où vous utilisez un outil pour générer du code à partir du modèle et vous incluez ce code dans votre projet (il doit être fait à nouveau après chaque changement dans le modèle). Pour les modèles basés sur EDMX, vous pouvez utiliser EdmGen.exe pour générer des vues. Pour les modèles basés sur le code, vous pouvez utiliser EF Power Tools CTP1.
EDMX (le concepteur) a été amélioré dans VS 2010 SP1 pour pouvoir travailler avec de grands modèles mais je pense toujours que le gros dans ce cas est d'environ 100 entités/tables. Dans le même temps, vous avez rarement besoin de 715 tables dans le même modèle. Je crois que ces 715 tables modèlent en effet plusieurs domaines afin que vous puissiez les diviser en plusieurs modèles.
La même chose est vraie lorsque vous utilisez DbContext et le code en premier. Si vous modélisez une classe pensez-vous que c'est un design correct quand la classe expose 715 propriétés? Je ne le pense pas mais c'est exactement ce que votre dérivé DbContext ressemble - il a une propriété publique pour chaque ensemble d'entités exposées (dans le mappage le plus simple, cela signifie une propriété par table).
La même entité peut être utilisée dans plusieurs modèles mais vous devriez essayer de l'éviter autant que possible car cela peut introduire des complexités lors du chargement d'entité dans un type de contexte et son utilisation dans un autre type de contexte.
Code uniquement = code first = Cadre d'entité lorsque vous définissez le mappage dans le code sans utiliser EDMX.
En plus de ce @Ladislav a suggéré, je pense faire edmx sur la base des modules peut aider dans ce scénario, comme pour admin ont edmx séparé, pour le module d'achat une autre edmx de même pour d'autres modules – Deepesh
J'ai installé la puissance EF outils et créé un modèle de code uniquement à partir de la base de données existante. Cela semble certainement mieux fonctionner que d'avoir l'EDMX. Cependant, j'ai toujours le problème que l'ajout d'un enregistrement envoie le programme dans lala. Comment puis-je comprendre ce qui ne va pas? –
Plusieurs contextes vous posent des problèmes lorsque vous utilisez des migrations EF, car cela suppose une base de données == un contexte, oui? –