Шаблон репозитория - Контекст и отображение данных
Я знаю, что есть много вопросов по шаблону репозитория, но я надеюсь, что кто-то будет достаточно любезен, чтобы помочь мне понять некоторые принципы.
Я всегда вижу конструктор класса репозитория, использующий контекст, и этот контекст часто является EF или NHibernate. Его тогда легко использовать dbset<T> для методов CRUD. Поскольку я не использую ничего подобного, а вместо этого делаю вызовы к источнику данных не-SQL через вызовы API, я не могу понять, как использовать Repository<T> и такой метод, как T GetById(int id) когда нет основного контекста, который знает, как перевести <T> направо Нужно ли создавать собственный контекст и свое собственное отображение данных? Буду ли я иметь специальный репозиторий для каждого класса, который у меня есть? Как-то, где-то, я должен взять это <T> и знать, что это для того, чтобы создать его и заполнить его свойства.
Я видел несколько примеров, когда шаблон репозитория используется с файлом, и похоже, что каждый тип имеет свой собственный репозиторий, в котором выполняется вызов и отображение.
Какие-нибудь примеры Шаблон репозитория, который предназначен для нескольких источников данных?
1 ответ
Шаблон репозитория - это концепция, независимая от одного или нескольких источников данных, одна из целей которых состоит в том, чтобы абстрагировать все связанные с сохранением данные. Я думаю, что вам нужен пример реализации репозитория, где используется более одного типа персистентности. Это очень просто, так как репозиторий (как реализация) - это просто класс, который не имеет ничего общего с Ef или чем-то еще.
На самом деле, большинство примеров, которые вы видели, "неправильны", потому что просто оборачивая контекст Db или NH без чего-либо еще, он ничего не делает.
Дело в том, что хранилище использует все необходимые ему источники данных. Это может быть только один (наиболее распространенный случай) или это может быть 2-3. Допустим, файл загружен, и вы хотите сохранить файл в файловой системе (или отправить его в облаке?) И сохранить некоторые метаданные в местный дб.
Хранилище будет использовать в качестве зависимости DAO (например, контекст EF) для связи с локальной базой данных и доступа к файловой системе напрямую. Если файл должен быть загружен в облако, хранилище также будет зависеть от поставщика облака.
Здесь нет ничего сложного, репозиторий просто использует БД и облако, скрывая их от остальной части приложения. Приложению не важно, где и как вы будете хранить этот файл. Поэтому, когда вы пишете класс Repository, вы можете делать все, что захотите, при условии соблюдения контракта (интерфейса).