Linq a SQL: Proiezioni, ViewModels, query non traducibili

Question

La mia applicazione deve gestire grandi quantità di dati, la normale dimensione selezionata è di circa 10000 righe. Per migliorare le prestazioni, si consiglia di selezionare solo i dati necessari.

Quando devo fare calcoli o qualsiasi attività significativa, mi sento a mio agio nel selezionare tutti i dati al fine di creare un'istanza corretta del mio modello in modo da poter fare affidamento sulla sua funzionalità.

Quando si visualizzano solo i dati (il più delle volte in una tabella) questo non è quello che voglio, voglio limitare la quantità di dati recuperati al minimo assoluto.

Finora ho usato il seguente approccio per ottenere dati dai miei repository (mostrato sotto è il metodo che fa tutto il magico dentro il repository:

private IEnumerable<TResult> GetAllProject<TResult>(Expression<Func<T, TResult>> selector, Expression<Func<T, bool>> predicate)
{
    SetReadContext();
    var query = DataContex.Table<Order>().Where(predicate).Select(selector);

    return query.ToList();
}

In questo modo ho la definizione del tipo per il tipo anonimo nel metodo che richiama il repository e posso lavorare in modo trasparente con il tipo lì.

Ogni controller può definire esattamente quali dati passare alla vista, è molto efficiente in quanto posso influenzare direttamente l'ordinamento delle colonne, ecc. senza dover gestire il controllo griglia nella vista per fare ciò per me. Non ho bisogno di LoadOptions su DataContext perché lo capisce in base al selettore.

Il problema ora è che non ho il controllo del selettore che viene passato al mio repository. Potrebbe contenere anche invocazioni di metodi ecc. che non sono traducibili.

La mia domanda è:

1. Finora ho evitato di creare ViewModels perché temo l'esplosione del tipo. Qual è il modo migliore per implementarli? Devo rendere disponibili i selettori che eseguono la proiezione per me?
2. Devo scrivere test unit che non controllano nulla ma se la query viene eseguita senza eccezioni?

Answer 1

Ti consiglierei di creare ViewModels in modo che tu stia lavorando con un set di classi noto, Type Explosion non è davvero un problema, dal momento che attualmente stai usando tipi anonimi, che probabilmente sono un po 'più difficili da gestire.

Se (di solito) hai un singolo ViewModel per View, allora diventa perfettamente pulito. In alcuni casi puoi persino condividere i tuoi ViewModel, anche se lo sconsiglierei perché prima o poi uno dei consumatori ha bisogno di più dati / campi e l'altro finisce con un ViewModel gonfio.