29 votes

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

Je suis en train de travailler sur une application web à l'aide de ASP.NET 3.5. L'application a des centaines de tableaux. On m'a dit dans un séminaire que je devrais en utiliser un .Fichier DBML pour l'ensemble de l'application au lieu d'utiliser plusieurs .DBML fichiers (il y a aussi un post sur stackoverflow que dit la même chose). Étant donné que j'ai beaucoup de tableaux avec un .Fichier DBML un sens ou suis-je mieux de la création de plusieurs .DBML fichiers qui sont regroupés logiquement?

Par exemple, je pense à la création de la suivante .DBML fichiers:

  • Client
  • Vendeur
  • Employé
  • Ordre De Vente

L'une des préoccupations que j'ai sur l'utilisation de plusieurs .DBML fichiers est comment je pourrais gérer les mises à jour à travers .DBML fichiers. Par exemple, si je devais mettre à jour un champ dans la table client lors d'une nouvelle commande a été saisie. Comment pourrais-je gérer cela? Je certainement ne voulez pas inclure la table client à la fois pour le Client et la Commande de Vente .DBML fichiers. Pourrais-je envelopper les opérations dans un TransactionScope?

Je ne sais pas si la suite a aucun impact sur la réponse, mais mon plan est d'utiliser le modèle de référentiel et des classes POCO de sorte que les références à la table des définitions dans le .DBML fichier sera local dans ma couche d'accès aux données.

Merci

11voto

jinsungy Points 3902

Je dois vous conseillons d'utiliser UN fichier dbml pour tous vos tables.

Si vous essayez de joindre deux tables de données différents contextes, il rend votre code plus complexe. Il peut être fait par la simulation de la croix contexte rejoint, mais pourquoi mettez-vous dans cette situation. Keep it simple stupid.

Aussi, si vous décidez d'aller avec 2 ou plus dbml fichiers et vous avez tort d'ajouter le même tableau de données multiples contextes, alors vous obtiendrez un "Ce membre est défini plusieurs fois" erreur.

6voto

Steven Points 56939

J'ai travaillé sur un projet de l'équipe qui a décidé de séparer le domaine dans quatre différentes DBML fichiers. La principale raison de cette régurgitations a eu à faire avec LINQ to SQL designer. Le designer n'était pas construit pour être utilisé avec de grands domaines.

Ces quatre "sous-domaines" dans ce projet ont été raisonnablement distinct, mais il y a des chevauchements et ce peu de nous à tout moment. Avec cette expérience, je vous conseille d'utiliser un seul fichier DBML par domaine. Habituellement, vous aurez un domaine pour la base de données, donc cela veut dire qu'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 de tous les temps), mais c'est un autre débat. Toutefois, lorsque vous décidez d'aller avec plusieurs DBML fichiers, et un cas d'utilisation où vous avez besoin de créer plusieurs DataContext de classes, 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 que j'utilise la plupart du temps, même avec un seul DataContext. Cependant, la création de la connexion et de transaction sont extraites de suite, donc il n'y a qu'un seul endroit dans le code où la transaction est effectuée.

2voto

Brian Mains Points 31772

J'ai un assez gros projet avec plus de 200 tableaux et il fonctionne très bien dans un contexte de données; puisque toutes les données sont assez interconnectés (conçu entre la 2ème et la 3ème forme normale), il peut être une douleur à l'utilisation de données multiples contextes.

Contexte plusieurs questions ne serait pas amusant dans les domaines où l'application a besoin de faire une requête sur les tables qui sont divisés; vous auriez à s'assurer que certaines tables sont séparées des données des contextes peu importe, car de la façon dont LINQ œuvres et de la hiérarchie. Au moins à partir d'un point de vue de la commodité, non pas qu'il ne pouvait pas être fait.

HTH.

0voto

Will Marcouiller Points 11649

Je voudrais utiliser un fichier DBML par le contexte. Par le contexte, je veux dire l'opération devant être effectuée par votre utilisateur comme elle/il est dans une fenêtre de votre application. Par exemple :

  1. Vous disposez d'une interface graphique vous permettant de gérer vos objets de Client ; Je ne puis envisager d'avoir un CustomerManagementDataContext au sein de laquelle je voudrais ajouter que les tableaux de gestion de la clientèle tâches connexes, et tous les depencies.

De cette façon, vous pouvez avoir un contexte pour 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 de fto inclure toutes les tables dans votre fichier DBML, mais ensuite, c'est un contexte un peu plus compliqué, et ne pas les tables relatives à votre client de gestion ou autre, selon le contexte que vous avez construit.

En effet, pour la facilité d'utilisation, il n'est ni mal de l'utiliser seul, mais ce n'est pas une bonne pratique, si je peut le mentionner.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X