Instructions DRY LINQ pour les tables avec des colonnes communes

Question

Voici un problème intéressant. Existe-t-il un moyen d'écrire du code en utilisant LINQ to SQL qui est capable d'effectuer une table UPDATE en sachant seulement que la table donnée contient les colonnes x, y, z mais ne sachant pas au moment de la compilation à quelle table elle traite?

J'ai plusieurs tables dans mon schéma de base de données qui partagent certaines colonnes et je dois appliquer une opération UPDATE basée sur un ensemble qui est identique dans sa procédure logique, quelle que soit la table concernée. Voici un exemple simple: disons que vous avez 3 tables qui implémentent une hiérarchie de modèle de contiguïté (ie chaque ligne contient un ID de clé primaire et une colonne d'identification parent auto-référencée). Chacune des tables a aussi un drapeau booléen 'Disabled'. Lorsque je désactiver une instance de l'une de ces entités, il devrait en cascade à travers les éléments enfants, à savoir

MISE À JOUR MyTable SET disabled = 1 WHERE ID = @ID ou PARENT_ID = @ID

Je ne vouloir écrire ces types d'instructions LINQ pour chaque entité, cela viole DRY. Cela peut sembler trivial avec cet exemple, mais comme l'exemple devient plus complexe, vous dupliquez des quantités croissantes de code. Je suis sûr qu'il doit être possible d'utiliser une interface et peut-être des génériques, mais j'ai du mal à trouver une solution élégante.

Answer 1

La solution d'Ali fonctionnerait (merci pour votre contribution) mais après avoir fait plus de recherche ma solution préférée est un 'mix-in' en utilisant des interfaces et des méthodes d'extension.

http://msdn.microsoft.com/en-us/vcsharp/bb625996.aspx

http://mikehadlow.blogspot.com/2008/05/interface-extension-methods-mixin.html

Cela présente plusieurs avantages 1) Je n'ai pas tripatouiller le mécanisme de l'autoproduction des classes LINQ dans VS2008 pour soutenir la nouvelle classe de base

2 Il n'y a pas d'implémentation d'une hiérarchie d'héritage sur mes classes LINQ, j'ajoute juste une interface à la déclaration de classe partielle et soudainement toutes ces nouvelles fonctionnalités partagées arrivent à la fête!

3) Si nécessaire, je pourrais mettre les méthodes d'extension dans leur propre espace de nom et les clients pourraient les échanger pour d'autres implémentations.

Commentaires sur cette approche appréciés

Answer 2

Créez simplement une classe de base pour vos entités et déplacez-y les propriétés communes en tant que propriétés virtuelles. Substituez ces propriétés dans vos entités et spécifiez les attributs Column sur celles-ci. Voici un détail example.

Answer 3

Les classes LINQ to SQL sont simplement des classes .NET standard qui prennent en charge une interface IQuery qu'elles traduisent en SQL. (Pas exactement une vague de main)

Vous pouvez créer votre propre implémentation IQuery et la diriger vers l'implémentation LINQ to SQL IQuery générée pour la table appropriée. Vous ajoutez une propriété appelée 'TableName' et remplacez 'Where' pour le prendre en charge.

Cette réponse n'est peut-être pas une solution complète, mais j'espère qu'elle peut vous orienter dans la bonne direction.