Design del repository per diversi provider

Naviga le tue risposte
1

Se l'obiettivo è essere in grado di scambiare provider di back-end DB (EF, OleDB, ODBC, ecc.) allora mi chiedo dove cambia il DB CRUD differente? Attualmente ho un'interfaccia (IGenericContext) che ha funzioni Aggiungi / Aggiorna / Elimina / Seleziona. Quindi faccio un ADOContext che implementa questo e all'interno di queste funzioni è dove faccio le istruzioni SQL. Per Aggiungi / Aggiorna / Elimina va bene, ma selezionare è interessante in quanto prendo solo una stringa che è la sql. Quindi nel mio repository, dove ho funzioni come GetAllTasks (), chiamo solo quel contesto.Seleziona la funzione con l'istruzione sql.

Tuttavia, se poi creo un EFContext non potreste chiamare questa funzione Select con la stringa sql. Faresti qualcosa che ha coinvolto Linq, il che significa che il mio repository ha bisogno del cambio di codice se cambio il contesto. Ora è meglio che il livello aziendale necessiti di un cambiamento, ma sembra ancora che sarebbe bello non dover cambiare il repository dato che è davvero il contesto che dovrebbe gestire quelle cose e che devono essere cambiate e per Update / Aggiungi / Elimina sì, ma la selezione sembra più unica per tipo di contesto.

Come gestiresti qualcosa del genere? Immagina di aver creato un contesto di file di testo per quella materia. Sembra che sia abbastanza facile nascondere i dettagli di Aggiungi / Aggiorna / Elimina ma è più difficile nascondere i dettagli di selezione dal contesto all'interno del repository.

    
posta user441521 05.08.2016 - 23:19
fonte

2 risposte

1

La tua interfaccia IGenericContext non cambierà, ma l'implementazione sottostante lo farà.

Ecco come funziona. L'interfaccia ti protegge dal dover apportare modifiche ai consumatori dell'interfaccia, se sei conforme all'interfaccia quando scrivi una nuova implementazione IGenericContext . Tuttavia, non ti solleva dal dover scrivere la nuova implementazione.

Per inciso, la tua affermazione che non puoi usare SQL con EF non è vera. Puoi ancora ottenere risultati da EF con SQL raw se vuoi: 

var students = context.Students.SqlQuery("SELECT * FROM dbo.Student").ToList();

o 

var student = context.ExecuteQuery<Student>(
    "SELECT * FROM dbo.Student WHERE StudentID = {0}", 1234)
    .FirstOrDefault();
    
risposta data 05.08.2016 - 23:40
fonte
0

Il modello di repository è un livello sopra il pattern di Mappatura dei dati. Da Fowler :

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects

Senza un livello di mappatura in atto, dovresti utilizzare Gateway dati tabella (noto anche come oggetto accesso ai dati) e / o Transaction Script invece.

L'obiettivo del modello di repository non è quello di consentire lo scambio dei provider di per sé. Questo è un effetto collaterale. E dai provider capita di significare diversi mapper O / RM come EF, NHibernate, ecc. Il vero vantaggio è che ti dà una cucitura che ti permette di testare la tua logica di dominio senza colpire il database usando un repository "In-memory" / unità di lavoro su cui puoi costruire i tuoi test unitari.

    
risposta data 06.08.2016 - 00:15
fonte

Leggi altre domande sui tag

Implementazione forzata di un'interfaccia per utilizzare una funzione, per abilitare funzionalità trasparenti per l'utente Dove si trova l'onere della responsabilità e del supporto di componenti / servizi condivisi?