Plusieurs classes DataContext sont-elles toujours appropriées?

Afin d'utiliser pleinement LinqToSql dans une application ASP.net 3.5, il est nécessaire de créer DataContext classes (ce qui est généralement fait en utilisant le concepteur dans VS 2008). Du point de vue de l'interface utilisateur, le DataContext est une conception des sections de votre base de données à laquelle vous souhaitez exposer via LinqToSql et qui fait partie intégrante de la configuration des fonctions ORM de LinqToSql.

Ma question est: Je suis en train de mettre en place un projet qui utilise une grande base de données où toutes les tables sont interconnectées d'une manière ou d'une autre par le biais des clés étrangères. Ma première tendance est de créer une énorme classe DataContext qui modélise la base de données entière. De cette façon, je pourrais en théorie (bien que je ne sache pas si cela serait nécessaire en pratique) utiliser les connexions de clé étrangère qui sont générées par LinqToSql pour passer facilement d'un objet à l'autre dans mon code, insérer des objets connexes, etc.

Cependant, après y avoir réfléchi, je pense qu'il serait plus logique de créer plusieurs classes DataContext, chacune se rapportant à un espace de noms spécifique ou à une section logique liée dans ma base de données. Ma principale préoccupation est que l'instanciation et l'élimination d'une énorme classe DataContext tout le temps pour des opérations individuelles qui se rapportent à des zones spécifiques de la base de données serait imposer une imposition inutile sur les ressources de l'application. En outre, il est plus facile de créer et de gérer des fichiers DataContext plus petits qu'un seul gros. Ce que je perdrais, c'est qu'il y aurait des sections distantes de la base de données qui ne seraient pas navigables via LinqToSql (même si une chaîne de relations les relie dans la base de données actuelle). De plus, certaines classes de tables existeraient dans plus d'un DataContext.

Des réflexions ou une expérience sur la question de savoir si plusieurs DataContexts (correspondant aux espaces de noms DB) sont appropriés à la place (ou en plus) d'une très grande classe DataContext (correspondant à la base de données entière)?

0

5 Réponses

Je me disputais sur la même question tout en ajustant rétro LINQ à SQL sur une base de données héritée. Notre base de données est un peu bizarre (150 tables) et après quelques réflexions et expérimentations, j'ai choisi d'utiliser plusieurs DataContexts. Si cela est considéré comme un anti-modèle reste à voir, mais pour l'instant, il rend la vie gérable.

0
ajouté

Je ne suis pas d'accord avec la réponse acceptée. Dans la question posée, le système possède une seule base de données volumineuse avec de fortes relations de clé étrangère entre presque toutes les tables (également le cas où je travaille). Dans ce scénario, le décomposer en DataContexts (DC's) plus petits a deux inconvénients immédiats et majeurs (tous deux mentionnés par la question):

  1. You lose relationships between some tables. You can try to choose your DC boundaries wisely, but you will eventually run into a situation where it would be very convenient to use a relationship from a table in one DC to a table in another, and you won't be able to.
  2. Some tables may appear in multiple DC's. This means that if you want to add table-specific helper methods, business logic, or other code in partial classes, the types won't be compatible across DC's. You can work around this by inheriting each entity class from its own specific base class, which gets messy. Also, schema changes will have to be duplicated across multiple DC's.

Maintenant, ce sont des inconvénients importants. Y a-t-il des avantages assez grands pour les surmonter? La question mentionne la performance:

Ma principale préoccupation est d'instancier et de disposer d'un énorme   DataContext classe tout le temps pour les opérations individuelles qui se rapportent   à des zones spécifiques de la base de données serait imposer un inutile   imposition sur les ressources de l'application.

En fait, il n'est pas vrai qu'un grand contrôleur de domaine prend beaucoup plus de temps à instancier ou à utiliser dans une unité de travail typique. En fait, après la création de la première instance dans un processus en cours, les copies suivantes du même contrôleur de domaine peuvent être créées presque instantanément .

Le seul véritable avantage de plusieurs contrôleurs de domaine pour une seule base de données volumineuse avec des relations de clés étrangères approfondies est que vous pouvez compartimenter un peu mieux votre code. Mais vous pouvez déjà le faire avec des classes partielles.

De plus, le concept d'unité de travail n'est pas vraiment pertinent pour la question initiale. L'unité de travail fait généralement référence à la quantité de travail qu'une instance DC est en train de faire, et non pas à combien travaille un DC classe est capable de le faire.

0
ajouté

Je pense que John a raison.

"Ma principale préoccupation est qu'instancier et disposer une énorme classe DataContext tout le temps pour les opérations individuelles qui se rapportent à des zones spécifiques de la base de données serait imposer une imposition inutile sur les ressources de l'application"

Comment soutenez-vous cette déclaration? Quelle est votre expérience qui montre qu'un DataContext volumineux est un goulot d'étranglement? Avoir plusieurs datacontextes ressemble beaucoup à avoir plusieurs bases de données et a du sens dans des scénarios similaires, c'est-à-dire presque jamais. Si vous travaillez avec plusieurs datacontexts, vous devez suivre les objets appartenant à quel datacontext et vous ne pouvez pas relier les objets qui ne sont pas dans le même contexte de données. C'est une odeur de conception coûteuse pour aucun avantage réel.

@Evan "Le DataContext (ou Linq to Entities ObjectContext) est plus une" unité de travail "qu'une connexion" C'est précisément pourquoi vous ne devriez pas avoir plus d'un datacontext. Pourquoi voudriez-vous plus qu'une «unité de travail» à la fois?

0
ajouté
Oui, l'OP n'est pas correct en supposant qu'un DC important prend plus de temps à instancier. En fait, après la création de la première instance dans un processus en cours, les instances suivantes du même contrôleur de domaine peuvent être créées presque instantanément.
ajouté l'auteur Jordan Rieger, source

Je ne suis pas d'accord avec la réponse de John. Le DataContext (ou Linq to Entities ObjectContext) est plus une «unité de travail» qu'une connexion. Il gère le suivi des modifications, etc. Voir ce billet pour une description:

Durée de vie d'un LINQ to SQL DataContext

Les quatre points principaux de ce blog sont DataContext:

  1. Est idéalement adapté pour une approche "unité de travail"
  2. est également conçu pour Fonctionnement du serveur "sans état"
  3. n'est pas conçu pour     Utilisation à long terme
  4.   Doit être utilisé très soigneusement après
    toute opération SumbitChanges ().
     

Compte tenu de cela, je ne pense pas que l'utilisation de plus d'un DataContext puisse nuire, en effet, créer des DataContexts différents pour différents types de travail contribuerait à rendre votre LinelToSql plus facile à utiliser et mieux organisé. Le seul inconvénient est que vous ne seriez pas capable d'utiliser sqlmetal pour générer automatiquement votre dmbl.

0
ajouté

Dans mon expérience avec LINQ to SQL et LINQ to Entities, DataContext est synonyme de connexion à la base de données. Donc, si vous deviez utiliser plusieurs magasins de données, vous auriez besoin d'utiliser plusieurs DataContexts. Ma réaction viscérale est que vous ne remarqueriez pas beaucoup de ralentissement avec un DataContext qui englobe un grand nombre de tables. Toutefois, si vous l'avez fait, vous pouvez toujours diviser logiquement la base de données aux points où vous pouvez isoler les tables qui n'ont aucune relation avec d'autres ensembles de tables et créer plusieurs contextes.

0
ajouté