Devrais-je créer un modèle de données d'entité ADO.NET pour chaque table ou un modèle pour l'ensemble de la base de données?

Question

Êtes-vous censé utiliser un modèle de données d'entité ADO.NET pour chaque table? Ou un pour votre base de données entière où les relations sont également routées, etc ...

Answer 1

Faites-le pour toute la base de données. Si vous créez un modèle de données pour chaque table, vous ne pourrez pas naviguer dans les relations.

Si vous utilisez un contrôle de source d'extraction / fusion comme Subversion, sachez que le concepteur limite le code XML au point que Subversion a du mal à le fusionner. Dans ce cas, vous devez généralement régénérer le modèle entier à chaque fois ou le fusionner manuellement.

Answer 2

J'utilise un modèle de données d'entité pour les tables associées. En fonction de la taille de votre base de données, je ne créerais qu'un seul modèle s'il y avait moins de 20 ou 25 tables. Il est un peu coûteux de créer des modèles individuels pour chaque table car chaque modèle doit créer un objet EntityConnection.

Je trouve que je peux assez bien maintenir les modèles si j'ai entre 5 et 15 tables. Mon principal facteur décisif est la fonctionnalité. Je construis des applications d'ingénierie, j'ai ainsi par exemple environ 6 tables de composants en acier de construction. Ils sont tous dans un modèle. Ils partagent les mêmes attributs techniques, ce qui facilite la réutilisation de code spécifique à la manipulation de ces attributs.

Cela signifie que je peux instancier le modèle, créer les objets, manipuler / organiser ces objets dans un fichier de code commun. Toute modification devant être propagée dans la base de données peut être effectuée de manière très efficace.

La ligne de fond détermine vos besoins et votre fréquence d’utilisation pour les objets sous-jacents. Si vous souhaitez mettre à jour en permanence une ou deux tables, il n’est pas logique d’avoir 30 autres tables non liées dans ce modèle. Dans ce scénario où un petit nombre de tables est utilisé fréquemment, il peut être judicieux de créer des collections de ces objets, de les manipuler et de mettre à jour la base de données aux moments appropriés.

La vérification de la mémoire est beaucoup moins chère à effectuer que les E / S sur disque. Ceci est juste mon point de vue sur le cadre et je ne suis en aucun cas un expert en la matière.

Answer 3

Une pour l'ensemble de votre base de données ou au moins les tables que vous utiliserez ...

Si vous avez un grand nombre de tables, vous pouvez les diviser en schémas ou d'une autre manière catégorique, mais je dirais que l'idée n'a jamais été de modèle de données par table ...

Answer 4

Je concevrais un modèle conceptuel / objet des données indépendamment du schéma de base de données, puis créerais le mappage qui relie le mieux le modèle conceptuel au schéma de base de données. Il peut utiliser la plupart des tables, sinon toutes. Si vous souhaitez un mappage un-à-un avec des tables, vous pouvez envisager d'utiliser LINQ-to-SQL, car il est plus facile de travailler avec.

Answer 5

Outre les réponses ci-dessus, n'oubliez pas qu'un modèle EF est en fait à un niveau conceptuel. Cela n'a pas besoin de rien à voir avec la structure de votre base de données, et n'a certainement pas besoin de représenter toute la base de données.

Answer 6

Je pense que si vous avez une base de données volumineuse, vous devez classer les tables de la base de données. Mais vous devez créer une classe pour chaque table qui constitue une exigence principale du framework d’entités ado.net.

Lorsque vous mettez à jour la base de données, vous pouvez le faire avec le modèle de données de mise à jour.

Concevez d’abord votre base de données, puis créez un modèle d’entité ado.net.