dichiarazioni LINQ secco per le tabelle con le colonne comuni

Question

Ecco un interessante problema. C'è un modo per scrivere del codice utilizzando LINQ to SQL che è in grado di eseguire un'UPDATE tabella conoscendo solo che la tabella è dato contiene colonne x, y, z, ma non conoscendo in fase di compilazione quale tabella si sta affrontando?

Ho diversi tavoli nel mio schema di DB che condividono alcune colonne e ho bisogno di applicare un'operazione di UPDATE set base che è identico nel suo procedimento logico indipendentemente da quale uno dei tavoli abbiamo a che fare.

Ecco un semplice esempio: supponiamo di avere 3 tavoli che implementano una gerarchia modello adiacenze (cioè ogni riga contiene un ID di chiave primaria e una colonna ID genitore autoreferenziale). Ognuna delle tabelle ha anche un 'handicap' flag booleano. Quando ho disabilitare un'istanza di una qualsiasi di queste entità, dovrebbe cascata attraverso gli elementi figlio, cioè.

MyTable UPDATE SET Disabilitato = 1 WHERE ID = @ID o parent_id = @ID

Non voglio di scrivere questo tipo di dichiarazioni LINQ per ogni entità, viola SECCO. Potrebbe sembrare banale con questo esempio, ma come l'esempio diventa più complesso si sta duplicando crescenti quantità di codice. Sono sicuro che deve essere possibile utilizzando un'interfaccia e forse farmaci generici, ma sto lottando per trovare una soluzione elegante.

Answer 1

La soluzione di Ali avrebbe funzionato (grazie per il vostro input), ma dopo aver fatto qualche ricerca più la mia soluzione preferita è un 'mix-in' con interfacce e metodi di estensione.

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

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

Questo ha diversi vantaggi 1) Non ho a giocherellare con il meccanismo generazione automatica delle classi LINQ in VS2008 per supportare la nuova classe di base

2) Non è far rispettare una gerarchia di ereditarietà sulle mie classi LINQ, mi basta aggiungere un'interfaccia per la dichiarazione della classe parziale e improvvisamente tutta questa nuova funzionalità condiviso arriva alla festa!

3) Se necessario, ho potuto mettere i metodi di estensione nel proprio spazio dei nomi e clienti potevo scambiare fuori per altre implementazioni.

Commenti apprezzate su questo approccio

Answer 2

LINQ to SQL classi sono solo classi .NET regolari che supportano un'interfaccia IQuery che si traducono in SQL. (Non esattamente una mano-wave)

Si può essere in grado di creare una propria implementazione IQuery e puntarlo alla LINQ generato all'attuazione SQL IQuery per la tabella appropriata. Si aggiunge una proprietà chiamata 'TableName' e di esclusione 'Dove' per sostenerlo.

Questa risposta non può essere una soluzione completa, ma spero che può puntare nella giusta direzione.

Answer 3

È sufficiente creare una classe di base per le entità e spostare le proprietà comuni ad esso, come le proprietà virtuali. Sovrascrivere queste proprietà a proprie entità e specificare gli attributi di colonna su di loro. Ecco una dettagliata esempio .