Un Linq à Sql - Plusieurs fichiers .DBML ou un fichier .DBML

Question

Je travaille sur une application web en utilisant ASP.NET 3.5. L'application a des centaines de tables. On m'a dit dans un séminaire que je devrais utiliser un fichier .DBML pour l'ensemble de l'application au lieu d'utiliser plusieurs fichiers .DBML (il y avait aussi un post dans stackoverflow qui disait la même chose). Étant donné que j'ai tellement de tables en utilisant un fichier .DBML, est-ce logique ou est-il préférable de créer plusieurs fichiers .DBML qui sont logiquement groupés?

Par exemple, je pensais à la création des fichiers .dbml suivants:

• client
• Fournisseur
• employé
• Commande

L'une des préoccupations que je avoir à propos de l'utilisation de plusieurs fichiers .DBML est de savoir comment je gérerais les mises à jour à travers les fichiers .DBML. Par exemple, si je devais mettre à jour un champ sur la table client lors de la saisie d'une nouvelle commande client. Comment pourrais-je gérer cela? Je ne veux certainement pas inclure la table client dans les fichiers .DBML Customer et Sales Order. Pourrais-je envelopper les opérations dans un TransactionScope? Je ne sais pas si les éléments suivants ont un impact sur la réponse, mais mon plan est d'utiliser le modèle de référentiel et les classes POCO afin que les références aux définitions de table dans le fichier .DBML soient locales à mon accès aux données couche.

Merci

Answer 1

Je dois vous conseiller d'utiliser ONE fichier dbml pour toutes vos tables.

Si vous essayez de join two tables from different data contexts, cela rend votre code plus compliqué. Cela peut être fait par simulating cross context joins, mais pourquoi vous mettre dans cette situation. Gardez-le simple stupide. En outre, si vous décidez d'utiliser deux fichiers dbml ou plus et que vous ajoutez par erreur la même table à plusieurs contextes de données, vous obtiendrez un "This member is defined more than once” error.

Answer 2

J'ai travaillé sur un projet où l'équipe a décidé de séparer le domaine dans quatre fichiers DBML différents. La principale raison de ce crachement était liée au concepteur LINQ to SQL. Le concepteur n'a pas été construit pour être utilisé avec de grands domaines.

Ces quatre «sous-domaines» dans ce projet étaient raisonnablement séparés, mais il y avait un certain chevauchement et cela nous a toujours mordu. Avec cette expérience, je vous conseille d'utiliser un seul fichier DBML par domaine. Habituellement, vous aurez un domaine par base de données, ce qui signifie un fichier DBML par base de données. Personnellement, je suis contre l'utilisation de TransactionScope dans le code de production (mais je l'utilise pour les tests d'intégration tout le temps), mais c'est une autre discussion. Toutefois, lorsque vous décidez d'aller avec plusieurs fichiers DBML, et un cas d'utilisation où vous devez créer plusieurs classes DataContext, vous pouvez les exécuter dans la même transaction, comme suit:

using (var con = new SqlConnection("constr")) 
{ 
    con.Open(); 
    using (var tran = con.BeginTransaction()) 
    { 
     using (var context = new CustomerDataContext(con)) 
     { 
      // do some work with it 
      context.SubmitChanges(); 
     } 

     using (var context = new VendorDataContext(con)) 
     { 
      // do some work with it 
      context.SubmitChanges(); 
     } 
    } 
} 

C'est le modèle J'utilise la plupart du temps, même avec un seul DataContext. Cependant, la création de la connexion et de la transaction est abstraite, de sorte qu'il n'y a qu'un seul endroit dans le code où la transaction est faite.

Answer 3

J'ai un assez grand projet avec 200 tables et ainsi de suite et cela fonctionne très bien dans un contexte de données; Puisque toutes les données sont assez interconnectées (conçues entre la 2ème et la 3ème forme normale), il serait difficile d'utiliser plusieurs contextes de données.

Plusieurs problèmes de contexte ne seraient pas amusants dans les domaines où l'application doit effectuer une requête sur les tables qui sont divisées; vous devez vous assurer que certaines tables se trouvent dans des contextes de données séparés, en raison du fonctionnement de LINQ et de la hiérarchie des niveaux. Au moins d'un point de vue de commodité, pas que cela ne pouvait pas être fait.

HTH.

Answer 4

J'utiliserais un fichier DBML par contexte. Par contexte, je veux dire l'opération à effectuer par votre utilisateur car il/elle est dans une fenêtre particulière de votre application. Par exemple:

1. Vous avez une interface graphique vous permettant de gérer vos objets clients; Je considérerais alors avoir un CustomerManagementDataContext dans lequel j'ajouterais les tables pour des tâches de gestion de client liées, et toutes les dépendances.

De cette façon, vous pouvez avoir un contexte par la fenêtre, si vous voyez ce que je veux dire. Mais tout dépend de votre modèle relationnel, cela pourrait être plus facile d'inclure toutes les tables dans votre fichier DBML, mais ensuite, cela crée un contexte un peu plus compliqué, et ne pointe pas les tables liées à la gestion de vos clients ou sinon, en fonction du contexte que vous avez construit.

En effet, pour la facilité d'utilisation, il n'est pas mauvais d'en utiliser un seul, mais ce n'est pas une bonne pratique, si je peux le mentionner.