Question

Afin d'utiliser pleinement LinqToSql dans un ASP.net 3.5 application, il est nécessaire de créer DataContext les classes (ce qui est généralement effectué à l'aide du concepteur de dans VS 2008).À partir de l'INTERFACE utilisateur perspective, le DataContext est une conception de la articles de votre base de données que vous souhaitez exposer à travers LinqToSql et fait partie intégrante de la configuration de l'ORM caractéristiques de LinqToSql.

Ma question est:Je suis en train de monter un projet qui utilise une grande base de données où toutes les tables sont reliées par des Clés Étrangères.Mon premier réflexe est de faire une énorme DataContext de la classe qui modélise l'intégralité de la base de données.De cette façon, je pourrais en théorie (mais je ne sais pas si cela serait nécessaire dans la pratique) utiliser la Clé Étrangère connexions qui sont générés par le biais de LinqToSql déplacer facilement entre les objets liés dans mon code, insérer des objets liés, etc.

Cependant, après avoir réfléchi, je suis en train de penser qu'elle pourrait faire plus de sens de créer plusieurs DataContext classes, chacune se rapportant à un espace de noms spécifique ou logique interdépendants de la section au sein de ma base de données.Ma principale préoccupation est que l'instanciation et l'élimination d'un énorme DataContext de la classe de tous les temps pour les opérations individuelles qui se rapportent à des domaines spécifiques de la Base de données serait impose une imposition sur les ressources de l'application.En outre, il est plus facile de créer et de gérer des petits DataContext de fichiers que d'une seule grande.La chose que je voudrais perdre est qu'il y aurait un lointain sections de la base de données qui permettrait de ne pas être navigable à travers LinqToSql (même si une chaîne de relations qui les relie dans la base de données).En outre, il y aurait une table classes qui existent dans plus d'un DataContext.

Toute pensée ou de l'expérience que plusieurs DataContexts (correspondant à DB espaces de noms) sont appropriés à la place de (ou en plus) d'une très grande classe DataContext (correspondant à l'ensemble de la DB)?

Était-ce utile?

La solution

Je suis en désaccord avec Jean-réponse.Le DataContext (ou Linq to entities ObjectContext) est une "unité de travail" que d'une connexion.Il gère le suivi des modifications, etc.Voir ce billet de blog pour une description:

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

Les quatre points principaux de ce blog sont que DataContext:

  1. Est idéal pour une "unité de travail" approche
  2. Est également conçu pour "apatrides" fonctionnement du serveur
  3. N'est pas conçu pour Longue durée d'utilisation
  4. Should be used very carefully after
    any SumbitChanges() operation.
    

Considérant que, je ne pense pas que l'aide de plus d'un DataContext ferait aucun mal - en fait, la création de différents DataContexts pour les différents types de travail pourrait aider à rendre votre LinqToSql impelmentation plus utilisable et organisé.Le seul inconvénient est que vous ne serait pas en mesure d'utiliser sqlmetal de générer automatiquement votre dmbl.

Autres conseils

J'avais été en proie au cours de la même question alors que le rétro côté LINQ to SQL sur un héritage DB.Notre base de données est un peu un whopper (150 tables) et après réflexion et d'expérimentation j'ai choisi d'utiliser plusieurs DataContexts.Si cela est considéré comme un anti-modèle reste à voir, mais pour l'instant il fait de la vie gérable.

Je pense que John est correct.

"Ma principale préoccupation est que l'instanciation et l'élimination d'un énorme DataContext de la classe de tous les temps pour les opérations individuelles qui se rapportent à des domaines spécifiques de la Base de données serait impose une imposition sur les ressources de l'application"

Comment avez-vous l'appui de cette affirmation?Quelle est votre expérience qui montre qu'un grand DataContext est un goulot d'étranglement des performances?Le fait d'avoir plusieurs datacontexts est un peu comme le fait d'avoir plusieurs bases de données et de sens dans des situations semblables, qui est, à peu près jamais.Si vous travaillez avec plusieurs datacontexts vous avez besoin de garder une trace de qui appartiennent les objets qui datacontext et vous ne pouvez pas relier les objets qui ne sont pas dans le même contexte de données.C'est une conception coûteux odeur pour aucun avantage réel.

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

Je suis en désaccord avec la accepté de répondre.Dans la question posée, le système a une unique grande base de données avec de fortes relations de clé étrangère entre presque chaque table (qui est aussi le cas là où je travaille).Dans ce scénario, le découper en petits DataContexts (DC) a deux immédiate et inconvénients majeurs (à la fois mentionné par la question):

  1. Vous perdez des relations entre des tables. Vous pouvez essayer de choisir votre DC limites à bon escient, mais vous finirez par être dans une situation où il serait très pratique d'utiliser une relation à partir d'une table dans un contrôleur de domaine à un tableau dans un autre, et vous ne serez pas en mesure de.
  2. Certains tableaux peuvent apparaître dans plusieurs DC. Cela signifie que si vous souhaitez ajouter une table spécifique des méthodes d'assistance, la logique d'entreprise, ou autre code dans les classes partielles, les types ne seront pas compatibles avec tous les dd.Vous pouvez contourner ce problème en héritant de chaque entité de la classe de sa propre classe de base, qui est malpropre.Aussi, les modifications de schéma devra être dupliqué sur plusieurs DC.

Maintenant ceux qui sont d'importants inconvénients.Existe-il des avantages assez grand pour les surmonter?La question mentionne la performance:

Ma principale préoccupation est que l'instanciation et l'élimination d'un énorme DataContext de la classe de tous les temps pour les opérations individuelles qui se rapportent les domaines spécifiques de la Base de données serait impose une l'imposition sur les ressources de l'application.

En fait, il n'est pas vrai qu'une grande DC prend beaucoup plus de temps pour instancier ou l'utilisation dans une unité typique de travail.En fait, après la première instance est créée dans un processus en cours, les copies subséquentes de la même DC peut être créé presque instantanément.

Le seul avantage réel à partir de plusieurs contrôleurs de domaine pour un seul, grande base de données complète des relations de clé étrangère est que vous pouvez compartimenter votre code un peu mieux.Mais vous pouvez déjà le faire avec des classes partielles.

Aussi, l'unité de la notion de travail n'est pas vraiment pertinent pour la question d'origine.Unité de travail se réfère généralement à la façon d'un travail d'un seul contrôleur de domaine exemple est en train de faire, pas beaucoup de travail d'un DC classe est capable de faire.

Dans mon expérience avec LINQ to SQL et LINQ to entities un DataContext est synonyme d'une connexion à la base de données.Donc, si vous avez été à l'utilisation de plusieurs banques de données, vous devez utiliser plusieurs DataContexts.Ma réaction instinctive est de vous ne serait pas l'avis de beaucoup de ralentir avec un DataContext qui englobe un grand nombre de tables.Si vous n'avez cependant vous pouvez toujours fractionner la base de données logiquement aux points où vous pouvez isoler les tables qui n'ont pas de relation avec d'autres ensembles de tables et de créer de multiples contextes.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top