Qual è la differenza tra un oggetto di query e un repository?

La tua domanda parla di repository essere IQueryable (cioè classi che implementano l'interfaccia IQueryable ), mentre la tua risorsa collegata parla di repository ritorno IQueryable oggetti . Non è la stessa cosa.

Ai fini di questa risposta, assumerò il tuo misspoke e intendo concentrarmi sui repository che restituiscono IQueryable objects.

What is the difference between Query Object and Repository?

Un oggetto query è essenzialmente un "un repository di metodi". La sintassi è leggermente diversa ma ogni oggetto di query è pensato per rispecchiare in modo efficace ciò che altrimenti sarebbe stato un metodo di repository. Vedo un piccolo vantaggio per interrogare gli oggetti a meno che tu non abbia un elevato bisogno di accoppiamento molto lento e molte query multi-entità che sono uniche per un particolare caso d'uso.

I heard Repositories should never be IQueryable

Qui ci sono considerazioni pro / contro. Tuttavia, mentre inizialmente ero con il lato di congedo (lasciando che i repository perdessero / fossero IQueryables), ho cambiato posizione dopo averne visto le conseguenze.

C'è un vantaggio diretto a filtrare IQueryables dai repository: è necessario scrivere meno metodi boilerplated nel repository. Per piccoli progetti (personali), ho perso IQueryables (e talvolta ignorato del tutto il livello del repository) per ridurre al minimo lo sforzo di sviluppo richiesto, non voglio sprecare il mio tempo scrivendo diversi metodi "ottieni dati" che funzionano tutti in modo leggermente diverso. / p>

Ma è qui che l'argomento antipattern entra nella mischia. Quando aggiungi un livello, lo fai con l'intenzione di separare due cose. In questo caso, il repository separa l'archiviazione dei dati dalla logica aziendale.

Quando perdi IQueryables dal tuo repository, stai effettivamente permettendo alla logica aziendale di controllare direttamente l'archiviazione dei dati, il che significa che non sono disconnessi l'uno dall'altro, il che significa che lo scopo del livello del repository (separare la logica di business dall'archivio dati) è stato annullato.

Ci sono anche altri problemi con questo:

• La testabilità è ostacolata. Diventa molto più difficile prendere in giro correttamente i tuoi repository quando stai testando la tua logica di business.
• Quando si esegue il debug di un problema nella logica dell'archivio dati, è necessario considerare anche la logica aziendale per determinare quali dati vengono recuperati.
• Uno sviluppatore che lavora solo sulla logica di business e nient'altro, è in qualche modo ancora tenuto a sapere quale archivio dati sottostante viene utilizzato.
  • Ad esempio, quando si utilizza LINQ e Entity Framework, EF non può gestire ogni codice LINQ valido. Ci sono alcune cose che semplicemente non si traducono in SQL e pertanto EF non può gestirle.
  • Pertanto, lo sviluppatore della logica di business è tenuto a sapere che EF viene utilizzato, il che vanifica lo scopo di aver disgiunto la logica di business dall'archivio dati.

Nei progetti personali o su piccola scala, questo non è tanto un problema. Ma in soluzioni di livello enterprise, le cose come la testabilità e la separazione delle preoccupazioni sono molto importanti.

Per riepilogare
Gli svantaggi derivanti dalla divulgazione di IQueryables violano diversi standard professionali di codifica. Tuttavia, quando gli standard di codifica non sono elevati nell'elenco delle priorità, o il codice non viene utilizzato in termini di capacità professionale, la fuoriuscita di IQueryables può ridurre al minimo i tempi di sviluppo necessari.