Il modello di repository deve essere utilizzato solo con Entity Framework?

Ho utilizzato Entity Framework e repository pattern per un po 'di tempo.Il modello di repository deve essere utilizzato solo con Entity Framework?

L'altro giorno mi è stato chiesto di scrivere un livello dati senza utilizzare Entity Framework, semplicemente il vecchio ADO.NET. Mi stavo chiedendo quale sarebbe l'approccio migliore per questo? Utilizzo anche un pattern di repository per le mie operazioni CRUD utilizzando semplicemente ADO.NET vecchio?

Se si passa a Codeplex e si cerca il modello di repository, il 99,9% di tutti i progetti di esempio utilizza Entity Framework. Esiste un modello diverso che deve essere utilizzato se utilizzo ADO.NET semplice con stored procedure?

fonte

2013-04-10 Brendan Vogt

NO, assolutamente no. Il modello di repository è un modello generico per l'accesso ai dati, che può essere utilizzato ogni volta che si accede ai dati, indipendentemente da come * esattamente si accede ai dati. –

Infatti, l'intero * punto * di utilizzo del modello di repository consiste nell'isolare l'applicazione dal modo in cui si accede ai dati. Che spesso sia EF è una testimonianza di quanto sia utile questa struttura, o della scarsità di alternative in dotnetland. – millimoose

No, il pattern di repository viene utilizzato estesamente al di fuori di Entity Framework ed è un modo utile per la gestione dell'accesso ai dati.

Da MSDN

Si centralizza la logica di accesso ai dati di logica o di un servizio Web.
Fornisce un punto di sostituzione per i test unitari.
Fornisce un'architettura flessibile che può essere adattata man mano che la progettazione generale dell'applicazione si evolve.

http://msdn.microsoft.com/en-us/library/ff649690.aspx

Altri vantaggi:

semplice per aggiungere la logica nel repository, come ad esempio i risultati di caching più di una richiesta Web
del possono essere aggiunti, interrogare comune come ad esempio userRepository.FindByEmailAddress(emailAddress);
Il repository può essere cambiato con un altro, ad esempio il passaggio da una base a un servizio Web con il minimo sforzo

fonte

2013-04-10 16:34:11

Martin Fowler "Patterns of Enterprise Architecture", fornisce la seguente definizione per un repository:

media tra il dominio e di dati di mappatura strati usando un'interfaccia per la raccolta simile per l'accesso oggetti di dominio.

Un modo comune per implementare che in C# è quello di avere un generico Repository<T> classe dove T è un oggetto persistente che implementa IQueryable<T> e fornisce metodi aggiuntivi come Add(entity), Remove(entity).

Sarebbe molto difficile implementare senza un ORM. È possibile creare un repository più semplice che consideri le dichiarazioni SQL come WHERE, ma può diventare disordinato.

Numerosi esempi utilizzano classi di repository concreti per ogni tipo con diversi metodi di persistenza. Ma queste sono solo delle classi DAO mascherate.

fonte

2013-04-10 16:37:55

Non sono del tutto d'accordo con te. I generici non esistevano nemmeno quando ha definito il modello. E sono numerosi esempi che usano collezioni in-memory per simularlo. – scartag

Ho appena fornito un modo comune per implementare i repository. È possibile semplificare l'implementazione per utilizzare le istruzioni SQL per restituire e materializzare gli oggetti. –

I repository generici sono negativi con un'eccezione: tutti i repository sembrano uguali e persistono nello stesso posto (ad esempio archivi di dominio che memorizzano tutto in una tabella in forma serializzata). Iqueryable esposto da un repository è un pattern anti per 2 motivi: 1) Presuppone che un oggetto business è identico all'entità sottostante dell'archivio dati, la maggior parte delle volte un'entità ORM e 2) Iqueryable specifica COME per creare una query quando questo è il preoccupazione del repository. Non devi dire al repository COME fare cose, devi dirgli quello che vuoi da esso. – MikeSW

Non penso che sia la strada giusta. Ma ci sono alcune ipotesi

Aggiunta di un modello di deposito sopra al codice EF. Questo ti allontana dalle caratteristiche del tuo ORM.Entity Framework è già un livello di astrazione sul tuo database.

Se si desidera utilizzare l'iniezione di dipendenza e lo sviluppo basato su test su EF, si segue il modello di repository. Usando RP il tuo codice diventa testabile e Iniettabile/manutenibile.

Fuori dagli schemi EF non è molto testabile, ma è abbastanza facile creare una versione mockable del contesto di dati EF con un'interfaccia che può essere iniettata.

Se non vogliamo che il nostro codice sia testabile o iniettabile, non usare RP.

ho visto un post sul blog: http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern

fonte

2013-04-11 09:28:11 JSJ

Ma hai visto questo post? http://www.sapiensworks.com/blog/post/2012/10/10/Do-We-Need-The-Repository-Pattern.aspx;) – MikeSW

Non avevo visto il post. Forse dovrei scrivere un nuovo post sul blog di Nogginbox chiamato "Quando dovrei usare il pattern del repository con un ORM". Un sacco di buoni motivi nel post di Sapiens Work sul perché lo faresti. Se vuoi solo avvolgere il tuo ORM per renderlo testabile, allora no. Se si dispone di più origini dati che si desidera nascondere o si prevede di sostituire il livello dati in un secondo momento, allora sì. –

Il modello di repository deve essere utilizzato solo con Entity Framework?

risposta

Problemi correlati