Терминология персистентности объекта: «хранилище» и «хранилище», «контекст», «извлечение» и (...)

Question

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

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

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

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

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

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

• хранилище : это звучит очень широко.Означает ли это что-то доступное для чтения / записи?
• store : это звучит как что-то, что потенциально дает доступ для записи.
• context : звукиочень абстрактноЯ видел это с помощью LINQ и объектно-реляционных картографов (ORM). PS (несколько месяцев спустя): это, вероятно, подходит для контейнеров, которые содержат «активные» или иным образом контролируемые объекты (приходит на ум шаблон единицы работы).
• retriever : звучит как что-то только для чтения.
• источник & сток : возможно, не подходит для сохранения объекта;лучше подходит для потоков данных?
• ридер / писатель : вполне понятен в своем намерении, но звучит слишком технически для меня.

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

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

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

---

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

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