oggetto persistenza terminologia: 'repository' vs 'store' vs 'contesto' vs 'retriever' contro (...)

Question

Non sono sicuro di come dare un nome classi memorizzare i dati durante la progettazione di livello di accesso ai dati di un programma di (DAL).

(By memorizzare i dati di classe, voglio dire una classe che è responsabile di leggere un oggetto persistente in memoria, o a persistere un oggetto in memoria.)

Sembra ragionevole per citarne una classe di archivio dati secondo due cose:

• quali tipi di oggetti gestisce;
• se è carica e/o persiste tali oggetti.

⇒ Una classe che carica gli oggetti Banana può essere chiamata ad es. BananaSource.

non so come fare per il secondo punto (es. Il Source po 'nell'esempio). Ho visto diversi nomi apparentemente utilizzati solo per tale scopo:

• repository: questo suona molto generale. Questo denota qualcosa di accessibile in lettura/scrittura?
• negozio: questo suona come qualcosa che potenzialmente permette l'accesso in scrittura.
• contesto: suona molto astratto. Ho visto questo con LINQ e mappatori di oggetti relazionali (ORM).
  P.S. (alcuni mesi più tardi): questo è probabilmente appropriato per i contenitori che contengono oggetti "attivi" o altrimenti supervisionati (viene in mente il modello dell'Unità di lavoro).
• retriever: suona come qualcosa di sola lettura.
• source & sink: probabilmente non appropriato per la persistenza dell'oggetto; una migliore corrispondenza con i flussi di dati?
• lettore/scrittore: abbastanza chiaro nelle sue intenzioni, ma suona troppo tecnico per me.

Questi nomi sono arbitrari o ci sono significati ampiamente accettati/differenze semantiche dietro a ciascuno? Più in particolare, mi chiedo:

• Quali nomi sarebbero appropriati per archivi di dati di sola lettura?
• Quali nomi sarebbero appropriati per archivi di dati di sola scrittura?
• Quali nomi sono appropriati per archivi di dati di sola lettura che vengono occasionalmente aggiornati?
• Quali nomi sono appropriati per gli archivi dati di sola scrittura che vengono letti occasionalmente?
• Un nome si adatta ugualmente bene a tutti gli scenari?

Answer 1

Poiché nessuno ha ancora risposto alla domanda, inserirò ciò che ho deciso nel frattempo.

Solo per la cronaca, ho praticamente deciso a chiamare la maggior parte dei dati classi negozio repository. In primo luogo, sembra essere il termine più neutrale e non tecnico dalla lista che ho suggerito, e sembra essere perfettamente in linea con lo Repository pattern.

In generale, "repository" sembra adattarsi bene dove interfacce dati recupero/persistenza sono qualcosa di simile al seguente:

public interface IRepository<TResource, TId> 
{ 
    int Count { get; } 
    TResource GetById(TId id); 
    IEnumerable<TResource> GetManyBySomeCriteria(...); 
    TId Add(TResource resource); 
    void Remove(TId id); 
    void Remove(TResource resource); 
    ... 
} 

---

Un altro termine ho deciso di utilizzare è fornitore, che preferirò su "repository" ogni volta che gli oggetti vengono generati al volo anziché essere recuperati da un archivio di persistenza, o quando l'accesso a un archivio di persistenza avviene in modo puramente di sola lettura. (fabbrica Sarebbe inoltre opportuno, ma suona più tecnico, e ho deciso di non termini tecnici per la maggior parte degli utilizzi.)

PS: po 'di tempo è passato da quando scrivendo questa risposta, e ho aveva molte opportunità al lavoro per rivedere il codice di qualcun altro. Un termine che ho aggiunto al mio vocabolario è Servizio, che sto riservando per scenari SOA: potrei pubblicare uno FooService che è supportato da un repository o provider privato . Il "servizio" è fondamentalmente solo un sottile strato rivolto al pubblico sopra questi che si occupa di cose come autenticazione, autorizzazione o aggregazione/batch di DTO per il corretto "chunkiness" delle risposte del servizio.