Plusieurs modèles de données Linq avec la même table cartographiées dans chaque mappage Réutiliser

Question

Je l'ai mis en œuvre le modèle référentiel sur la couche d'accès aux données de notre couche de service actuelle.

Nous avons un modèle d'objet où la même classe « notes historiques » est mis en correspondance sur mutiple objets (actuellement 6 mais bientôt plus!)

Une partie des meilleures pratiques pour l'utilisation de LINQ to SQL est de ne pas avoir un fichier dbml pour chaque table dans la db, mais au lieu de le décomposer, de cette façon, il ne dispose pas d'une performance énorme succès lorsque le contexte est créé.

Malheureusement, les endroits logiques pour séparer les objets laisse les notes historiques dans 5 différents fichiers DBML. Lorsque le générateur de LINQ crée les classes qu'il génère une classe différente dans les différents espaces de noms.

J'ai un objet de note historique dans le modèle de domaine, mais je ne veux pas re-mapper le modèle objet de domaine dans le modèle de données pour chaque fois que nous utilisons les notes historiques.

L'une des choses que je ne veux pas faire est de briser la « lecture » des données dans plusieurs requêtes.

Est-il possible que je peux cartographier la note historique en plusieurs modèles de données, mais seulement écrire une fois la mise en correspondance?

Merci

Pete

Solution

Merci pour l'aide, je pense que je vais revenir à un contexte de données pour toutes les tables de données.

Les travaux contournements impliqués dans la mise en place des multiples modèles ne vaut pas la complexité supplémentaire et la fragilité potentielle du code. Avoir à écrire la même main gauche, le code de droite pour cartographier les notes historiques est trop de travail et trop d'endroits pour garder le code de synchronisation.

Merci les gars pour l'entrée

Answer 1

  

Une partie des meilleures pratiques pour l'utilisation   de LINQ to SQL est de ne pas avoir un dbml   déposer pour chaque table dans la db, mais   au lieu de le décomposer, de cette façon il   ne dispose pas d'un énorme succès de la performance   lorsque le contexte est créé.

Où avez-vous entendu? Je ne suis pas d'accord. Le DataContext est généralement un objet assez léger, quel que soit le nombre de tables.

Voir ici pour une analyse des problèmes impliquant plusieurs contextes de données:

LINQ to SQL: contexte unique de données ou plusieurs Contextes de données http://craftycodeblog.com / 2010/07/19 / LINQ-to-sql-unique-données-contexte ou multiples /

À mon avis, vous devriez avoir une datacontext par base de données. Cela permettrait également de résoudre vos problèmes de cartographie.

Voir aussi LINQ to SQL: Multiple / Simple .dbml par projet

Answer 2

Une option pourrait être de mettre les notes historiques dans leur propre datacontext, et de garder les relations entre cet objet et le reste de votre modèle comme « ids » (donc juste des clés étrangères dans la db). Voilà comment je le ferais de toute façon.