Schema del repository Procedura dettagliata Spiegazione [chiuso]

276

Qualcuno può spiegarmi il modello di repository in .NET, passo dopo passo fornendo un esempio o una demo molto semplice.

So che questa è una domanda molto comune, ma finora non ho trovato una risposta soddisfacente.

c# asp.net design-patterns repository

— Sa Patil
fonte

msdn.microsoft.com/en-us/library/ff649690.aspx e codeproject.com/Tips/309753/...

— Maarten

C'è un buon commento

— ssmith

Risposte:

199

In sintesi, descriverei l'impatto più ampio del modello di repository. Consente a tutto il codice di utilizzare oggetti senza dover sapere come gli oggetti sono persistenti. Tutta la conoscenza della persistenza, incluso il mapping dalle tabelle agli oggetti, è contenuta in modo sicuro nel repository.

Molto spesso troverai query SQL sparse nella base di codice e quando arrivi ad aggiungere una colonna a una tabella devi cercare i file di codice per provare a trovare gli usi di una tabella. L'impatto del cambiamento è di vasta portata.

Con il modello di repository, è necessario modificare solo un oggetto e un repository. L'impatto è molto piccolo.

Forse sarebbe d'aiuto pensare al motivo per cui dovresti usare il modello di repository. Ecco alcuni motivi:

Hai un unico posto per apportare modifiche al tuo accesso ai dati
Hai un unico posto responsabile di un set di tabelle (di solito)
È facile sostituire un repository con un'implementazione falsa per i test, quindi non è necessario disporre di un database disponibile per i test delle unità

Ci sono anche altri vantaggi, ad esempio, se stavi usando MySQL e volessi passare a SQL Server, ma in pratica non l'ho mai visto!

— Fenton
fonte

Passando da dbms ab, andrò a registrare che non solo l'ho visto, l'ho fatto anche nel codice di produzione. In precedenza utilizzavamo Oracle, dovevamo cambiare provider di hosting, optare per Azure (prima che supportassero Oracle), quindi abbiamo dovuto convertire in SQL Azure. Sfortunatamente, a quel punto non avevamo separato tutta la logica di accesso ai dati, ma sicuramente l'abbiamo fatto come abbiamo fatto per quella migrazione (e in futuro, potrei aggiungere).

— Joe,

So che questo commento è vecchio e chiuso come fuori tema, ma l'ho visto fatto in più aziende. In genere, fa parte di un processo per spostarsi verso o lontano da un ORM. Il repository rende più semplice la sua disattivazione, specialmente se li carichi da un modello di fabbrica astratto o usando un contenitore IoC.

— Derek Van Cuyk,

In realtà Repository utilizza DAO per le operazioni relative all'origine dati ...

— Yousha Aleayoub,

@YoushaAleayoub che buon punto hai sollevato. In genere troverai oggetti di accesso ai dati quando le persone stanno cercando di "separare il database" e repository quando le persone stanno cercando di "rendere una singola cosa responsabile della query". In quasi tutti i casi, troverai entrambi insieme. La parte DAO è il IConnection, ICommand, ecc parte che nasconde il tipo di database. Il repository è generalmente più incentrato sul dominio.

— Fenton,

181

Questo è un bell'esempio: l'esempio del modello di repository in C #

Fondamentalmente, il repository nasconde i dettagli di come i dati vengono recuperati / persistenti da / nel database. Sotto le coperte:

per la lettura, crea la query che soddisfa i criteri forniti e restituisce il set di risultati
per la scrittura, emette i comandi necessari per far salvare i dati dal motore di persistenza sottostante (ad esempio un database SQL)

— Duefiori
fonte

Questo esempio è la migliore spiegazione di sempre, semplicemente migliore della documentazione MSDN.

— Teoman shipahi,

Ho trovato questo molto buono. Fornisce anche una spiegazione decente sull'Unità di lavoro, che sembra essere una forma più generica del modello di dati sul modello di

— deposito

L'esempio collegato è un errore del modello di repository. Non offre alcun vantaggio rispetto all'utilizzo delle interfacce fornite da Entity Framework ( IDbContext) o direttamente in nhibernate ( ISession). Un repository correttamente implementato estrae TUTTE le informazioni specifiche sulla persistenza (come il funzionamento dell'attuale provider Linq To Sql). cioè non esporre mai IQueryable.

— jgauffin,

@jgauffin IQueryablenon è un'informazione specifica sulla persistenza. Il supporto di IQueryable potrebbe essere semplice come un array hard coded o potrebbe provenire da un file XML, un servizio Web, un database, un file flat, ecc. Non consiglierei un repository che non esponesse IQueryable come sempre porta ad un accesso lento ai dati in ogni caso, in cui l'esposizione di IQueryable consentirà ad alcune istanze di migliorare le prestazioni laddove applicabile se l'archivio di persistenza ha tale capacità. Inoltre, nascondere DbContext ti consente di passare a un ORM diverso se necessario (o no ORM!)

— Robert McKee

Perdono informazioni specifiche sulla persistenza. Prova a utilizzare il caricamento impaziente / lento o la creazione di una INclausola sql senza sapere come lo fa il provider LinqToSql specifico.

— Jgauffin,