Create a new entity/repository just for this report?
Nuove entità, sì, repository, no. Ma vengo a questa risposta da una prospettiva leggermente diversa:
Penso che sia sempre una buona idea avere un DbContext sottotipo separato per la segnalazione. Questo contesto specializzato può essere ottimizzato per le prestazioni rendendolo di sola lettura:
-
Disattiva il caricamento lento e la creazione di proxy:
context.Configuration.ProxyCreationEnabled = false;
-
Disattiva rilevamento modifiche:
context.Configuration.AutoDetectChangesEnabled = false;
-
(Forse) disabilita la convalida:
context.Configuration.ValidateOnSaveEnabled = false;
Ma sarebbe utile solo se c'è la possibilità che vengano fatte chiamate di SaveChanges involontarie.
-
Disattiva il salvataggio delle modifiche eseguendo l'override del metodo SaveChanges senza chiamare base.SaveChanges .
Inoltre, se il contesto espone anche proprietà DbSet<T> , dovresti usarli con AsNoTracking() , che impedirà il tracciamento delle entità.
Se hai un tale contesto, è più ovvio utilizzarlo con entità specializzate, non con le entità che appartengono all'altra, i contesti aziendali. Questo può essere entità che acquisisce esattamente il risultato di una stored procedure. È anche possibile popolare più entità con una stored procedure .
W.r.t. repository - Io non sono un fan di loro comunque. I repository, se usati con EF, dovrebbero essere repository generici . I repository generici non contengono metodi specifici per tipo, quindi finiscono sempre per essere un involucro sottile (praticamente inutile) attorno a DbSet s. Puoi anche lavorare con DbSet s direttamente (o con l'output delle stored procedure).
Un'altra cosa da ricordare: anche con queste ottimizzazioni, EF non è lo strumento più veloce per leggere i dati da un database. Potresti voler dare un'occhiata a Dapper .