I repository dovrebbero restituire IQueryable?

Ho visto molti progetti con repository che restituiscono istanze di IQueryable. Ciò consente ulteriori filtri e l'ordinamento può essere eseguito su un IQueryablealtro codice, che si traduce in diversi SQL generati. Sono curioso di sapere da dove provenga questo schema e se sia una buona idea.

La mia più grande preoccupazione è che IQueryableè una promessa di colpire il database qualche tempo dopo, quando viene elencato. Ciò significa che un errore verrebbe generato all'esterno del repository. Ciò potrebbe significare che un'eccezione Entity Framework viene generata in un diverso livello dell'applicazione.

In passato ho anche riscontrato problemi con i set di risultati attivi multipli (MARS) (soprattutto quando si utilizzano le transazioni) e questo approccio sembra che ciò comporterebbe che ciò accada più spesso.

Ho sempre chiamato AsEnumerableo ToArrayalla fine di ciascuna delle mie espressioni LINQ per assicurarmi che il database venisse colpito prima di lasciare il codice del repository.

Mi chiedo se la restituzione IQueryablepotrebbe essere utile come blocco predefinito per un livello dati. Ho visto del codice piuttosto stravagante con un repository che chiama un altro repository per crearne uno ancora più grande IQueryable.

La restituzione di IQueryable offrirà sicuramente maggiore flessibilità ai consumatori del repository. Mette la responsabilità di restringere i risultati al cliente, che naturalmente può essere sia un vantaggio che una stampella.

Sul lato positivo, non sarà necessario creare tonnellate di metodi di repository (almeno su questo livello) - GetAllActiveItems, GetAllNonActiveItems, ecc. - per ottenere i dati desiderati. A seconda delle tue preferenze, di nuovo, questo potrebbe essere buono o cattivo. Si sarà (/ dovrebbe) necessario definire contratti comportamentali che le vostre implementazioni aderiscono, ma dove che va dipende da voi.

Quindi potresti mettere la logica di recupero grintosa al di fuori del repository e lasciarla usare come desidera l'utente. Quindi esporre IQueryable offre la massima flessibilità e consente query efficienti rispetto al filtraggio in memoria, ecc. E potrebbe ridurre la necessità di creare una tonnellata di metodi specifici per il recupero dei dati.

D'altra parte, ora hai dato ai tuoi utenti un fucile da caccia. Possono fare cose che potresti non aver inteso (abusando di .include (), fare query pesanti e pesanti e filtrare in memoria nelle loro rispettive implementazioni, ecc.), Che sostanzialmente farebbero da contropiede ai controlli di stratificazione e comportamentali perché hai dato accesso completo.

Quindi, a seconda del team, della loro esperienza, delle dimensioni dell'app, della stratificazione generale e dell'architettura ... dipende: - \

Esporre IQueryable a interfacce pubbliche non è una buona pratica. Il motivo è fondamentale: non è possibile fornire la realizzazione di IQueryable come si dice.

L'interfaccia pubblica è un contratto tra provider e clienti. E nella maggior parte dei casi c'è un'aspettativa di piena attuazione. IQueryable è un cheat:

1. IQueryable è quasi impossibile da implementare. E attualmente non esiste una soluzione adeguata. Anche Entity Framework ha molte UnsupportedExceptions .
2. Oggi i provider di query hanno una grande dipendenza dall'infrastruttura. Sharepoint ha un'implementazione parziale propria e il provider My SQL ha un'implementazione parziale distinta.

Il modello del repository ci dà una chiara rappresentazione mediante stratificazione e, soprattutto, indipendenza di realizzazione. Quindi possiamo cambiare in futuro fonte di dati.

La domanda è " Dovrebbe esserci la possibilità di sostituire l'origine dati? ".

Se domani parte dei dati può essere spostata nei servizi SAP, nella banca dati NoSQL o semplicemente in file di testo, possiamo garantire la corretta implementazione dell'interfaccia IQueryable?

( altri punti positivi sul perché questa è una cattiva pratica)

Realisticamente, hai tre alternative se vuoi un'esecuzione differita:

• Fallo in questo modo - esponi un IQueryable.
• Implementare una struttura che esponga metodi specifici per filtri specifici o "domande". ( GetCustomersInAlaskaWithChildren, sotto)
• Implementare una struttura che esponga un'API di filtro / ordinamento / pagina fortemente tipizzata e costruisca IQueryableinternamente.

Preferisco il terzo (anche se ho aiutato i colleghi a implementare anche il secondo), ma ovviamente ci sono alcune impostazioni e manutenzioni. (T4 in soccorso!)

Modifica : per chiarire la confusione che circonda ciò di cui sto parlando, considera il seguente esempio rubato da IQueryable può uccidere il tuo cane, rubare tua moglie, uccidere la tua volontà di vivere, ecc.

Nello scenario in cui esporresti qualcosa del genere:

public class CustomerRepo : IRepo 
{ 
     private DataContext ct; 
     public Customer GetCustomerById(int id) { ... } 
     public Customer[] GetCustomersInAlaskaWithChildren() { ... } 
} 

l'API di cui sto parlando ti permetterebbe di esporre un metodo che ti consentirebbe di esprimere GetCustomersInAlaskaWithChildren(o qualsiasi altra combinazione di criteri) in modo flessibile, e il repository lo eseguirà come IQueryable e ti restituirebbe i risultati. L'importante è che funzioni all'interno del livello repository, quindi sfrutta ancora l'esecuzione differita. Una volta ottenuti i risultati, puoi ancora LINQ-to-object su di esso a tuo piacimento.

Un altro vantaggio di un approccio come questo è che, poiché sono classi POCO, questo repository può vivere dietro un servizio web o WCF; può essere esposto ad AJAX o ad altri chiamanti che non conoscono la prima cosa su LINQ.

Esiste davvero una sola risposta legittima: dipende da come deve essere utilizzato il repository.

Ad un estremo il tuo repository è un wrapper molto sottile attorno a DBContext in modo da poter iniettare un'impiallacciatura di testabilità attorno a un'app basata su database. Non c'è davvero nessuna aspettativa nel mondo reale che questo possa essere usato in modo disconnesso senza un DB compatibile LINQ dietro di esso perché la tua app CRUD non ne avrà mai bisogno. Quindi certo, perché non usare IQueryable? Probabilmente preferirei IEnumarable poiché ottieni la maggior parte dei vantaggi [leggi: esecuzione ritardata] e non sembra così sporco.

A meno che non ci si trovi a quell'estremo, farei del mio meglio per sfruttare lo spirito del modello di repository e restituire raccolte materializzate appropriate che non hanno implicazioni su una connessione al database sottostante.

 > Should Repositories return IQueryable?

NO se si desidera eseguire test / sviluppo test-driven perché non esiste un modo semplice per creare un repository finto per testare il proprio businesslogic (= repository-consumer) in isolamento dal database o da altri provider IQueryable.

Dal punto di vista dell'architettura pura, IQueryable è un'astrazione che perde. Come generalità, fornisce all'utente troppa potenza. Detto questo, ci sono posti dove ha senso. Se si utilizza OData, IQueryable rende estremamente semplice fornire un endpoint facilmente filtrabile, ordinabile, raggruppabile ... ecc. In realtà preferisco creare DTO su cui le mie entità eseguono il mapping e IQueryable restituisce invece DTO. In questo modo pre-filtro i miei dati e utilizzo davvero solo il metodo IQueryable per consentire la personalizzazione dei risultati da parte del cliente.

Ho affrontato anche questa scelta.

Quindi, riassumiamo i lati positivi e negativi:

Positivi:

• Flessibilità. È sicuramente flessibile e conveniente consentire al lato client di creare query personalizzate con un solo metodo di repository

Aspetti negativi:

• Non testabile . (testerai l'implementazione IQueryable sottostante, che di solito è il tuo ORM. Ma dovresti invece testare la tua logica)
• Sfoca la responsabilità . È impossibile dire cosa fa quel particolare metodo del tuo repository. In realtà, si tratta di un metodo divino, che può restituire qualsiasi cosa ti piaccia nell'intero database
• Insicuro . Senza restrizioni su ciò che può essere richiesto da questo metodo di repository, in alcuni casi tali implementazioni possono non essere sicure dal punto di sicurezza.
• Problemi di memorizzazione nella cache (o, per essere generici, eventuali problemi di pre o post elaborazione). In genere non è saggio, ad esempio, memorizzare nella cache tutto nella propria applicazione. Tenterai di memorizzare nella cache qualcosa che causerà un carico significativo al tuo database. Ma come fare, se si dispone di un solo metodo di repository, che i client utilizzano per inviare praticamente qualsiasi query sul database?
• Problemi di registrazione . La registrazione di qualcosa a livello di repository ti farà ispezionare prima IQueryable per verificare se questa chiamata particolare viene registrata o meno.

Consiglierei di non utilizzare questo approccio. Prendi invece in considerazione la creazione di diverse specifiche e implementa metodi di repository, che possono interrogare il database usando quelli. Il modello di specifica è un ottimo modo per incapsulare un insieme di condizioni.

Penso che esporre l'IQueryable sul tuo repository sia perfettamente accettabile durante le fasi iniziali dello sviluppo. Esistono strumenti dell'interfaccia utente che possono funzionare direttamente con IQueryable e gestire ordinamento, filtro, raggruppamento, ecc.

Detto questo, penso che esporre il greggio sul repository e chiamarlo un giorno sia irresponsabile. Avere operazioni utili e helper di query per query comuni consente di centralizzare la logica di una query esponendo allo stesso tempo una superficie di interfaccia più piccola agli utenti del repository.

Per le prime iterazioni di un progetto, esporre pubblicamente IQueryable sul repository consente una crescita più rapida. Prima della prima versione completa, consiglierei di rendere l'operazione di query privata o protetta e di portare le query jolly sotto lo stesso tetto.

Quello che ho visto fare (e quello che sto implementando da solo) è il seguente:

public interface IEntity<TKey>
{
    TKey Id { get; set; }
}

public interface IRepository<TEntity, in TKey> where TEntity : IEntity<TKey>
{
    void Create(TEntity entity);
    TEntity Get(TKey key);
    IEnumerable<TEntity> GetAll();
    IEnumerable<TEntity> GetAll(Expression<Func<TEntity, bool>> expression);
    void Update(TEntity entity);
    void Delete(TKey id);
}

Ciò che ti consente di fare è avere la flessibilità di fare una IQueryable.Where(a => a.SomeFilter)query sul tuo repo facendo concreteRepo.GetAll(a => a.SomeFilter)senza esporre alcun business LINQy.