Afin d'utiliser pleinement LinqToSql dans une application ASP.net 3.5, il est nécessaire de créer DataContext classes (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 que vous souhaitez exposer via LinqToSql et fait partie intégrante de la configuration des fonctionnalités 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 via des clés étrangères. Ma première inclination est de créer une énorme classe DataContext qui modélise l'ensemble de la base de données. De cette façon, je pourrais en théorie (bien que je ne sache pas si cela serait nécessaire dans la pratique) utiliser les connexions de clé étrangère générées via LinqToSql pour passer facilement d'un objet lié à mon code, insérer des objets liés, etc.
Cependant, après y avoir réfléchi, je pense maintenant qu'il peut être plus logique de créer plusieurs classes DataContext, chacune se rapportant à un espace de noms spécifique ou à une section logique interdépendante au sein de ma base de données. Ma principale préoccupation est que l'instanciation et la suppression permanente d'une énorme classe DataContext pour des opérations individuelles liées à des zones spécifiques de la base de données imposeraient une imposition inutile sur les ressources de l'application. De plus, il est plus facile de créer et de gérer des fichiers DataContext plus petits qu'un seul gros. La chose 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 réelle). De plus, certaines classes de table existeraient dans plusieurs DataContext.
Avez-vous des idées ou une expérience sur la question de savoir si plusieurs DataContexts (correspondant aux espaces de noms de la base de données) sont appropriés à la place (ou en plus) d'une très grande classe DataContext (correspondant à l'ensemble de la base de données) ?
