Ну, не уверен, что это точно правильный заголовок, но в основном у меня возникло множество проблем с использованием репозиториев в приложениях MVC таким образом, что вы можете заменить один набор репозиториев, внедряя другую технологию хранения данных, для другой.
Например, предположим, что я хочу использовать Entity Framework для своего приложения. Тем не менее, я также хочу иметь набор тестовых данных, реализованных в жестко кодированных списках. Я хотел бы иметь набор интерфейсов (IUserRepository, IProductRepository и т.д.), Чтобы не говорить о более общем IRepository <T> на данный момент), что оба подхода могут создать экземпляр. Затем, используя (скажем) инструмент Injection Dependency, такой как Ninject или Castle Windsor, я могу переключаться между провайдером инфраструктуры сущностей (доступ к фактической базе данных) и поставщиком тестов (доступ к спискам).
В двух словах, здесь проблема:
- Если вы собираетесь использовать Entity Framework, вы хотите, чтобы ваши репозитории возвращали IQueryable <SomeType> .
- Если вы собираетесь использовать списки с жестким кодированием, вы НЕ хотите, чтобы ваши репозитории возвращали IQueryable, потому что он очень сильно добавляет накладные расходы, а плюс Linq to Entities значительно отличается от Linq to Objects, что вызывает много головных болей в коде, который является общим для обоих поставщиков.
Другими словами, я нашел, что лучший подход изолирует весь EF-зависимый код в репозиториях, так что сами репозитории возвращают IEnumerable или IList или некоторые из них - тогда как EF, так и некоторые другие технологии могут использовать один и тот же хранилища. Таким образом, все IQueryable будет содержаться В РЕГИОНАХ EF. Таким образом, вы можете использовать Linq для Entities с репозиториями EF и Linq для объектов с тестовыми репозиториями.
Однако этот подход ставит огромную часть бизнес-логики в репозитории и приводит к значительному дублированному коду - логика должна дублироваться в каждом из репозиториев, даже если реализации несколько отличаются.
Вся идея репозиториев как этого слоя, который очень тонкий и просто соединяется с базой данных, затем теряется - репозитории являются "репозиториями" бизнес-логики, а также связью хранилища данных. Вы не можете просто найти, сохранить, обновить и т.д.
Мне не удалось устранить это несоответствие между необходимостью изолировать код, зависящий от провайдера, и иметь бизнес-логику в централизованном месте.
Любые идеи? Если бы кто-нибудь мог указать мне пример реализации, который затрагивает эту проблему, я был бы весьма признателен. (Я много читал, но не могу найти ничего, что конкретно говорит об этих проблемах.)
UPDATE:
Я думаю, что я начинаю чувствовать, что, возможно, нет репозиториев, которые могут быть заменены для разных поставщиков, - что, если вы собираетесь использовать Entity Framework, например, вам просто нужно посвятить все свое приложение к платформе Entity Framework. Единичные тесты? Я борюсь с этим. Моя практика заключается в том, чтобы настроить отдельный репозиторий с жестко закодированными данными и использовать его для модульного тестирования, а также для тестирования самого приложения до того, как база данных будет настроена. Я думаю, мне придется искать другое решение, возможно, какой-то насмешливый инструмент.
Но тогда возникает вопрос о том, почему использовать репозитории, и особенно зачем использовать интерфейсы репозитория. Я работаю над этим. Я думаю, что определение наилучшей практики займет немного исследований.
