Utilizzo del modello di deposito

4

Sto usando il pattern di repository nella mia applicazione in questo momento. È uno strumento di elaborazione batch basato su console. Essenzialmente ho bisogno che il repository sia in grado di accedere in modo casuale ai dati. Il problema che sto avendo è che i miei dati devono essere:

  1. leggi una volta (da flat-file)
  2. accesso in modo casuale dal repository
  3. scritto una volta.

Lo gestisco nel codice utilizzando una clausola di guardia per vedere se i record sono stati ancora acceduti, e in caso contrario li leggo. Un semplice esempio sotto.

public IUnit GetById(int id)
{
    if (!ReadIn)
    {
         ReadAllUnitsFromFile();
    }
    return _listOfUnits[id];
}

La mia domanda è questa: Sarebbe una bastardizzazione del pattern del repository se avessi un modulo che funzionasse prima del resto del mio programma per leggere i dati nel repository, e un altro modulo che si è poi verificato per scrivere i dati dal repository? È un anti-modello? C'è un modello migliore per la mia situazione?

Grazie

    
posta Jeffrey Cameron 31.03.2011 - 14:47
fonte

3 risposte

6

L'intero punto del modello di repository consiste nel consentire all'utente di astrarre l'implementazione dietro un'interfaccia generica. Puoi utilizzare qualsiasi metodo che funzioni meglio per la tua situazione e, se desideri modificarlo in un secondo momento, non dovrebbe influire sul resto della tua applicazione.

Usa qualsiasi implementazione che funzioni al meglio (ed è la più facile da capire e mantenere).

    
risposta data 31.03.2011 - 15:20
fonte
3

Prenderò in considerazione la combinazione del modello Unità di lavoro con il modello di deposito.

L'unità di lavoro è simile a una transazione (e spesso ne include una) e sarebbe responsabile di comunicare al repository di caricare i dati inizialmente e di salvarli alla fine.

    
risposta data 31.03.2011 - 18:58
fonte
2

Penso che il miglior codice sia ciò che funziona (ed è pulito, verificabile, mantenibile ovviamente), indipendentemente dal fatto che implementa fedelmente qualche pattern o meno.

Se è necessario utilizzare la maggior parte o tutti i record durante l'elaborazione, a me sembra perfettamente corretto leggere tutti i dati prima e salvarli dopo. Il caricamento lento complica sempre il codice, può introdurre problemi di concorrenza ecc. Pertanto, vale la pena utilizzarlo solo se può effettivamente risparmiare tempo di esecuzione, quando spesso i dati non sono necessari o sono necessari solo in ritardo, oppure può essere caricato in piccole parti per migliorare i tempi di avvio.

Inoltre, AFAIK non ha nulla nel modello di deposito che richiede il carico pigro degli oggetti: sei libero di caricarli, tuttavia ti si adatta dietro le quinte. Per quanto riguarda il caricamento e il salvataggio degli elementi da parte di un modulo esterno diverso, questo potrebbe effettivamente interrompere l'incapsulamento dell'interfaccia, ma credo che sia possibile spostare quei moduli anche dietro l'interfaccia del repository - può avere metodi di inizializzazione e spegnimento.

    
risposta data 31.03.2011 - 14:55
fonte

Leggi altre domande sui tag