Entity Framework DataContexts

Question

Je me bats avec un design et essaye de trouver la meilleure façon de l'approcher.

Nous avons beaucoup de tables, et dans une implémentation LinqToSql actuelle, notre DBML a une taille de plusieurs mégas, très lourde. Je veux éviter de recréer cette situation si je le peux. Nous décidons de notre chaîne de connexion pour chaque utilisateur, il est donc très difficile de créer des dbml distincts pour différents groupes de tables. Je suis sur utiliser Entity Framework, et bien que nous n'ayons pas besoin des éléments du Code First, j'aime le code léger sans toute la génération et nous n'avons pas besoin de la cartographie visuelle donc je pensais à générer les fichiers de code pour toutes les tables, puis les ajouter dans un DataContext en tant que DbSets. Cela m'a amené à réfléchir aux meilleures pratiques ici, et je voulais poser la question;

Est-il judicieux de créer un DataContext pour chaque groupe de tables que vous souhaitez utiliser? C'est à dire. Je vais avoir un module, il sera responsable de la collecte des données à partir de 5 tables, il n'a pas besoin de chaque table unique dans la base de données, seulement 5. Dois-je créer un DbContext qui comprend ces 5 tables. Si j'ai besoin de plus dans le futur, je peux les ajouter, mais c'est léger.

Answer 1

Bien que vous puissiez avoir un contexte distinct pour chaque regroupement de tables, si votre modèle est grand ou si vos domaines sont disparates, vous pouvez envisager d'ajouter une couche d'abstraction. Par là, je veux dire avoir un seul contexte qui englobe tout votre modèle, puis ajouter quelque chose le long des lignes du repository pattern. This est un article décent sur l'accomplissement de cela avec EF. En faisant cela, accompliriez-vous essentiellement deux objectifs: extraire votre niveau de données, libérant ainsi les soucis de mise en œuvre; et, permettant à vos développeurs de travailler avec seulement les entités dont ils ont besoin, éventuellement regroupés par aggregate root.

Une chose que je voudrais préciser cependant. Je ne suggère pas nécessairement que vous allez avec une architecture de bout en bout spécifique (c'est-à-dire DDD). Ce que j'essaie de faire ici, c'est suggérer quelques modèles qui vous donneront la flexibilité de vous permettre de faire des erreurs (échouer gracieusement) tout en continuant à progresser dans votre projet.

Answer 2

Vous pouvez certainement le faire. Vous ajoutez simplement des tables au modèle edmx comme dans Linq2SQL. Ainsi, en ajoutant simplement les 5 tables dont vous avez besoin, vous économiserez sur les frais généraux pour le suivi des entités pour les autres tables non-suivies. Entity Framework ajoute joliment des propriétés de navigation bidirectionnelles que Linq2SQL n'a pas aussi. Je recommande d'utiliser EF au lieu de Linq2SQL.

Answer 3

Il n'y a rien de fondamentalement mauvais à propos d'un grand modèle DBML, l'impact sur les performances devrait être négligeable dans EF. D'autre part, à mon avis, la réduction de la complexité s'applique également à Entity Framework - si votre code n'a besoin que de 5 tables de la base de données, créez un contexte séparé qui n'a que les entités pour ces 5 tables. En factorisant des tables complètement indépendantes dans des contextes séparés, vous exprimez clairement cette séparation - il n'y a aucune dépendance de ces tables aux autres tables de votre base de données, et aucune dépendance du code aux entités non liées - si c'est le cas je pense (et il pourrait y avoir d'autres opinions) c'est la voie à suivre. Cependant, gardez à l'esprit que si vous avez besoin de certaines de ces tables dans un autre contexte, vous devez également placer les entités correspondantes dans ce contexte. Il peut être difficile de comprendre que les mêmes tables sont présentes dans plusieurs contextes ou même avoir des interdépendances entre les contextes. Cela devrait être évité car cela ajoute de la complexité.