Терминология сохранения объектов: "репозиторий" и "хранилище" по сравнению с "контекстом" по сравнению с "ретривером" против (...)

Я не уверен, как назвать классы хранилища данных при разработке уровня доступа к данным программ (DAL).

(По типу хранилища данных я имею в виду класс, который отвечает за чтение сохраненного объекта в памяти или сохранение объекта в памяти.)

Кажется разумным назвать класс хранилища данных в соответствии с двумя вещами:

какие объекты обрабатываются,
загружает и/или сохраняет такие объекты.

→ Класс, который загружает объекты Banana, может быть вызван, например. BananaSource.

Я не знаю, как обойти вторую точку (т.е. бит Source в примере). Я видел разные существительные, которые, по-видимому, использовались только для этой цели:

репозиторий: это звучит очень общее. Означает ли это что-то доступное для чтения/записи?
store: это похоже на то, что потенциально допускает доступ на запись.
контекст: звучит очень абстрактно. Я видел это с LINQ и объектно-реляционными mappers (ORM).
Постскриптум (несколько месяцев спустя): Вероятно, это подходит для контейнеров, которые содержат "активные" или контролируемые иным образом объекты (на ум приходит модель "Единица работы" ).
ретривер: звучит как что-то только для чтения.
источник и sink: возможно, не подходит для сохранения объектов; лучше подходит для потоков данных?
читатель/ писатель: совершенно ясно в своем намерении, но звучит слишком технично для меня.

Являются ли эти имена произвольными или есть общепринятые значения/семантические различия позади каждого? Более конкретно, я задаюсь вопросом:

Какие имена подходят для хранилищ данных только для чтения?
Какие имена подходят для хранилищ данных только для записи?
Какие имена будут соответствовать главным образом хранилища данных только для чтения, которые иногда обновляются?
Какие имена будут соответствовать главным образом хранилищам данных только для записи, которые иногда читаются?
Хорошо ли одно имя подходит для всех сценариев?

Ответ 1

Поскольку никто еще не ответил на вопрос, я опубликую на том, что я решил тем временем.

Как раз для записи, я довольно много решил вызвать большинство классов хранилища данных репозиториев. Во-первых, это, по-видимому, самый нейтральный, нетехнический термин из предложенного мной списка, и он, похоже, хорошо соответствует шаблону репозитория .

Как правило, "репозиторий", по-видимому, хорошо вписывается, где интерфейсы поиска/сохранения данных похожи на следующие:

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);
    ...
}

Другим термином, который я решил использовать, является провайдер, который я буду предпочитать поверх "репозитория" всякий раз, когда объекты генерируются "на лету", а не извлекаются из хранилища персистентности или когда доступ к хранилищу персистентности происходит исключительно для чтения. ( Factory также будет уместным, но звучит более технически, и я решил отказаться от технических терминов для большинства применений.)

P.S.: Прошло некоторое время с момента написания этого ответа, и у меня было несколько возможностей на работе, чтобы просмотреть код другого пользователя. Один термин, который я добавил в свой словарь, Сервис, который я резервирую для сценариев SOA: я могу опубликовать FooService, который поддерживается частным репозиторием или поставщиком Foo. "Сервис" - это, по сути, лишь тонкий публичный слой над ними, который заботится о таких вещах, как аутентификация, авторизация или агрегирование/пакетная обработка DTO для правильной "чанкильности" ответов службы.