IQueryable e repository – prendi 2?

Devo ammettere che ho portato il banner “Repository should not return IQueryable” perché è più difficile da testare. Sono stato influenzato dalle risposte ad altre domande come questa e questa .

Stamattina ho letto il blog di ScuttGu su ASP.NET vNext dove dettagliare Model Binding usando un SelectMethod che sembra fare affidamento su IQueryable per il paging e l’ordinamento.

Pensi che questo ci costringerà a riconsiderare il ruolo svolto da IQueryable nei repository?

Il DDD Repository dovrebbe incapsulare i dettagli tecnici dell’accesso ai dati:

Definizione: un repository è un meccanismo per incapsulare il comportamento di archiviazione, recupero e ricerca che emula una raccolta di oggetti.

È anche responsabile della gestione di middle e end of life degli oggetti di dominio. L’interfaccia del repository appartiene al dominio e dovrebbe basarsi il più ansible su Ubiquitous Language . Oltre al libro DDD, questi due articoli coprono quasi tutto ciò che è necessario sapere quando si progettano i repository:

  • Come scrivere un repository
  • Il deposito generico

Esporre IQueryable sull’interfaccia del repository non è ottimale secondo me. IQueryable non fa parte di Ubiquitous Language. È un tecnicismo, non ha un significato di dominio. Invece di incapsulare il reperimento dei dati, il repository esponeva il meccanismo di accesso ai dati, il che sostanzialmente elimina lo scopo di avere il repository in primo luogo.

Per quanto riguarda ASP.NET. Questa è una struttura dell’interfaccia utente. Perché dovresti consentire al framework dell’interfaccia utente di influenzare la progettazione del tuo modello di dominio? Gli esempi di Microsoft spesso incoraggiano cose come la griglia di dati dell’interfaccia utente legata direttamente alle tabelle del database. Oppure, più di recente, i controlli si sono associati a ciò che viene definito modello di dominio, mentre è in realtà un modello anemico o semplicemente un contenitore di dati stupido con get / set. La citazione dell’articolo che hai citato (ho messo un po ‘di enfasi):

Il binding del modello è un approccio incentrato sul codice per l’associazione dei dati . Ti permette di scrivere metodi di helper CRUD all’interno del file code-behind della tua pagina, e quindi collegarli facilmente a qualsiasi server-control all’interno della pagina. I controlli server si prenderanno quindi cura di chiamare i metodi al momento opportuno nel ciclo di vita della pagina e nei dati-legano i dati .

La mia interpretazione di questo è di abbandonare il modello e gli oggetti e bind i dati all’interfaccia utente. Questo è probabilmente un approccio valido e giustificato in molti casi. Ma dal momento che la domanda è stata contrassegnata come DDD, direi che in DDD questo è chiamato Smart UI Anti-Pattern .