2009-04-01 13 views
9

Come si comunica a un contesto dati LINQ di ignorare proprietà specifiche o tutte le proprietà di sola lettura quando si associa un set di risultati a un oggetto?Ignora proprietà della classe di sola lettura quando si utilizza DataContext.ExecuteQuery <T>

Sto lavorando con alcune istruzioni T-SQL che sono difficili da esprimere usando LINQ, quindi sto usando il metodo ExecuteQuery del contesto dati per passare il T-SQL dritto al database.

Se la mia classe T ha proprietà di sola lettura, ottengo eccezioni in fase di esecuzione quando il contesto dati tenta di impostare tali proprietà e ha esito negativo perché non c'è alcuna proprietà setter. Come faccio a dire al contesto di ignorare queste proprietà?

Questo è quello che sto facendo ora. Funziona, ma fa schifo:

public bool IsPaidInFull { 
    get { return NetTotal <= 0m; } 
    set { /* needed so linq doesn't choke. Should never be set by hand */ } 
} 
+0

Posso essere il primo a suggerire - "non _do_ quello"? –

+1

Non fare cosa, esattamente? La soluzione alternativa è un peccato ed è inaccettabile, quindi il mio post qui. Se intendi "non trovare un modo per saltare certe proprietà quando si vincola al set di risultati", potresti spiegare per favore? –

risposta

0

Avete considerato Linq come entità? Potrebbe non valere la pena di convertire il progetto, a seconda di quanto tempo ci si trova, o di quanto spesso ci si sente a proprio agio. Tuttavia, questo scenario esatto non costituirebbe un problema in Linq alle Entità. Non tenta di aggiornare le proprietà di sola lettura nell'oggetto quando lo carica, perché non sono mappate esplicitamente, sono semplicemente proprietà di estensione.

Inoltre, è possibile utilizzare la rotta old-school/java utilizzando le funzioni getter anziché le proprietà. public bool getIsPaidInFull() {return NetTotal < = 0m;}.

Oppure si può giocare con l'implementazione delle proprietà di sola lettura in una classe figlio ereditata, ma questo può introdurre tutti i tipi di problemi di tipo.

+0

Questa non è una possibile soluzione per questo progetto, purtroppo, ma grazie per il suggerimento. Penso che potremmo considerare un ORM completo in futuro; L2S è ottimo come semplice wrapper sul modello dati, ma può essere doloroso utilizzarlo come livello di mappatura per le entità. Accetto il tuo suggerimento "vecchia scuola" come risposta. Non riesco a trovare una soluzione migliore e i metodi getter sono migliori della mia attuale soluzione alternativa. –

1
public bool IsPaidInFull 
{ 
    get { return NetTotal <= 0m; } 
    private set { ;} 
} 
+0

Questo è il male ... –

+0

Deve avere qualcosa a che fare con il riflesso usato dal datacontext. Immagino che il datacontext usi il reflection per verificare se c'è un getter e setter sulla tua proprietà, ma non controlla il modificatore di accesso. E poi dato che non usa mai il setter, non c'è alcun problema con l'accesso. – AndyClaw

Problemi correlati