C# Linq: Pouvez-vous fusionner DataContexts?

Question

Dites que j'ai une base de données et que cette base de données possède un ensemble de tables générales pour tous les clients et certaines tables spécifiques à certains clients.

Maintenant, ce que j'ai à l'esprit crée un DataContext primaire qui inclut uniquement les tables qui sont générales à tous les clients, puis crée des DataContext s distincts qui contiennent uniquement les tables qui sont spécifiques au client.

---

est-il un moyen de genre de « fusion » DataContext s afin qu'il devienne un contexte? Donc pour le client A, j'ai besoin d'un DataContext qui inclut à la fois les tables générales et aussi les tables pour ce client spécifique (récupérées de deux DataContext s différents)?

---

[Mise à jour]

Ce que je pense que je peux faire est, de la classe partielle du DataContext au lieu de laisser mes DataContext hériter de DataContext je fais hériter de MyDataContext; De cette façon, les tables de MyDataContext et l'autre DataContext seront disponibles dans une classe DataContext.

Que pensez-vous de cette approche? Bien sûr, avec quelque chose comme ça, vous ne pouvez fusionner deux datacontexts à la fois si ...

Answer 1

Je ne suis pas au courant de toute façon d'y parvenir de façon progmatique.

Ce que vous pourriez vouloir regarder est en utilisant des modèles de conception pour atteindre cet objectif. En utilisant des modèles avec, par exemple, un modèle de référentiel, vous pouvez définir votre référentiel d'interface de base dont hériteront tous les référentiels clients. Ensuite, pour chaque référentiel client, vous étendez cela avec leurs besoins spécifiques.

Answer 2

J'utiliserais un motif de façade. Créez un contexte de façade qui résumerait le DataContext sous-jacent de l'utilisateur. Vous pouvez hériter de Default DataContext si vous le souhaitez et remplacer les méthodes. Dans les remplacements, vous pouvez le passer au DataContext approprié.

Answer 3

Je ne sais pas si vous l'avez déjà compris, mais la fusion de DataContexts n'est pas une bonne idée. Une grande partie de la raison a à voir avec le suivi des modifications qui est intégré dans l'objet DataContext. Si vous pouviez séparer les objets d'entité afin que les modifications n'affectent qu'un seul DataContext à la fois sans chevauchement, vous pouvez le faire fonctionner, mais cela semble être un problème si vous en payez si peu.

Vous pouvez implémenter un modèle de référentiel, mais encore une fois, vous avez toujours le problème avec un DataContext ne reconnaissant pas les objets créés avec un autre DataContext. Le projet que je suis en train de travailler n'utilise qu'un seul DataContext. La base de données compte environ 75 tables maintenant ... J'ai des relations un-à-un, un-à-man, et plusieurs-à-plusieurs et je n'ai pas encore rencontré de sérieux problèmes de performances ou de mise en œuvre en utilisant un seul DataContext . L'utilisation d'un modèle de façade peut fonctionner, mais encore une fois, vous devez vous demander si la maintenance de plusieurs DataContexts qui ne peuvent pas interagir directement en vaut la peine. Par exemple, supposons que vous ayez une table Client et une table Commandes. Par exemple:

La table Customer réside dans un DataContext et la table Orders réside dans l'autre. La relation est un client à zéro à plusieurs ordres. Comme vous les avez dans des DataContexts séparés, je ne crois pas que vous puissiez directement faire référence à l'objet entité enfant dans votre requête.Donc, pour obtenir les commandes pour un client particulier, vous pouvez être obligé de le faire:

var orders = DC2.Orders.Where(a => a.Customer_ID == (DC1.Customers.Where(a => a.Customer_ID == 7).Customer_ID); 

au lieu de ceci:

var orders = DC.Customers.Where(a => a.Customer_ID == 7).Select(a => a.Orders); 

Answer 4

Nous avons réalisé cela en utilisant l'héritage au sein DataContexts, nous utilisons EF5, Code-First et MVC4 pour les projets Web fron-end.

Nous avons un DataContext commun pour encapsuler toutes les tables communes dans notre base de données

public partial class CommonDataContext : DbContext 
{ 
    //Your code 
} 

Et plusieurs contextes de données spécialisées qui utilisent leurs propres tables + les tables communes

public partial class Application1Context : CommonDataContext 
{ 
    //Your code 
} 

Chacun de ces les contextes de données sont dans des projets séparés, à l'intérieur de la même solution. Espérons que cette aide.