Precaricare i dati con Linq-to-SQL, IOC e modello di repository

Question

utilizzando Linq-to-SQL vorrei precaricare alcuni dati.

1) la soluzione comune è gestire DataLoadOptions , ma nella mia architettura non funzionerà perché:

• le opzioni devono essere impostate prima della prima query
• Sto usando IOC, quindi non instanciare direttamente DataContext (non riesco ad eseguire il codice al momento dell'installazione)
• my DataContext è persistente per la durata di una richiesta web

2) Ho visto un'altra possibilità basata sul caricamento dei dati e relativi figli in un metodo, quindi restituendo solo i dati (quindi il figlio è già caricato) < a href = "http://www.west-wind.com/weblog/posts/38838.aspx" rel = "nofollow noreferrer"> vedi un esempio qui

Tuttavia, nella mia architettura, non può non funzionare:

• Le mie query sono in cascata dal mio repository e possono essere utilizzate da molti servizi che aggiungeranno clausole
• Lavoro con le interfacce, le istanze concrete degli oggetti linq-sql non escono dai repository (sì, puoi lavorare con le interfacce E aggiungere clausole)
• I miei repository sono generici

Sì, questa architettura è piuttosto complicata, ma è molto interessante dato che posso giocare con il codice come lego;)

La mia domanda è: quali sono le altre possibilità per precaricare un dato?

Answer 1

Nella mia app utilizzo forse una variante della tua potenziale soluzione n. 2. È un po 'difficile da spiegare ma semplicemente: concatengo e differisco il caricamento lento nel mio modello con classi pigre in modo da astrarre dall'esecuzione differenziata specifica di LinqToSql di cui approfitto con IQueryable . Vantaggi:

• Il mio modello di dominio e il livello di servizio verso l'alto non devono necessariamente dipendere dal provider LinqToSql (posso scambiare il mio DAL con interfacce se voglio)
• I miei metodi di servizio possono e restituiscono grafici a oggetti completi con più 'punti di ancoraggio' per il caricamento lento usando classi che astraggono una particolare implementazione di caricamento lento - quindi posso usare l'esecuzione differita specifica di LinqToSql o qualcos'altro (ad es. anon delegates di nuovo, fai riferimento a questa risposta )
• Posso mantenere i risultati IQueryable in tutta la mia app (anche nell'interfaccia utente, se lo desidero) consentendo così il concatenamento infinito di query LINQ senza doversi preoccupare delle prestazioni.

Answer 2

Non sono a conoscenza di altre possibilità, sembra che tu abbia spinto LinqToSql ai suoi limiti (potrei sbagliarmi, comunque).

Penso che le tue migliori opzioni a questo punto siano:

1. Aggiungi alcuni " non generici " metodi per l'applicazione per gestire solo il scenari specifici in cui si desidera / è necessario un caricamento rapido e non usa il tuo "normale", "generico" infrastruttura per tali metodi.
2. Utilizza un ORM con un supporto più sofisticato per il caricamento desideroso e lento.

Answer 3

Ho trovato una soluzione. La mia risposta è " Iniezione di dipendenza '.

Viene generalmente fornito con IOC e significa che è possibile far sì che il proprio contenitore IOC gestisca l'iniezione di classi al momento dell'istanza.

Tutto ciò di cui ho bisogno è iniettare una classe CustomDCParameter quando installo un controller di dominio. Quella classe conterrà le regole e il costruttore le applicherà tutte.