Шаблон репозитория C# в веб-API
У меня есть проект ASP.NET WEB API с репозиторием и архитектурой шаблона единицы работы. Моя цель проста: следовать шаблону внедрения зависимостей для поддержки тестируемой архитектуры. Меня интересует, как лучше всего внедрить репозиторий в соответствующий контроллер; Например: IUserRepository в UserController Заранее спасибо :)
Я использую Ninject
Думаю, к вопросу нужно добавить больше информации. Объясните, что вы пробовали, а что не работает. В Интернете есть множество ресурсов, которые объясняют, как использовать контейнер DI с WebAPI. Попробуйте сузить круг вопросов, которые не работают, потому что здесь задается очень широкий круг вопросов.
Спасибо за внимание :) я застрял в этих двух вариантах gist.github.com/kakha-tezela/49db5672fef19683f2e7d1dec6ddbc0 f
Внедрение конструктора - это то, что использует большинство людей, но я бы добавил базовый класс, чтобы у вас всегда была область действия UOW во всех подклассах.
Я использую структуру moq для своего модульного тестирования, и я высмеиваю зависимости, так какой из перечисленных выше способов лучше?
Ответы 2
Здесь, в статье, которую я написал, чтобы показать, как можно использовать UnitOfWork и иметь тестируемый (внедряющий зависимости) код.
https://www.codeproject.com/Articles/1157241/Very-Thin-Database-Layer-using-UnitOfWork-Pattern
Надеюсь это поможет
Прежде всего, спасибо, мой вопрос в том, как внедрить репозиторий в контроллер. например, Inject IunitOfWork или ICustomerRepository. Следуя вашему образцу, вы вводите IUnitOfWork. так ли это правильный путь? в виду модульное тестирование :)
Вы никогда не должны вводить Repo прямо в свой контроллер, у вас должна быть служба, которая содержит бизнес-логику и пишет тест для служб, чтобы вы могли имитировать IUnitOfWork. Если вы хотите написать интеграционные тесты, в которых вам не нужно ничего имитировать, просто вызовите реализацию Сервиса.
ага так в моем случае это было бы правильно gist.github.com/kakha-tezela/86ebe0ee8e288666150ce9a11c1e9ce a
«да», но оберните вашу единицу работы шаблоном Factory, чтобы вы не создавали DbContext сразу после создания Контроллером, потому что это может быть ненужным.
ага, и в моем проекте модульного тестирования я бы издевался над своим IUnitOfWork. спасибо за внимание и советы
Вообще говоря, старайтесь внедрять только те API / части вашего кода, которые вам нужны. В вашем примере это будет означать только репозиторий / репозитории, используемые вашим контроллером, а не всю единицу работы.
По мере роста вашего контроллера вам может потребоваться больше доступных методов (например, сохранение, которое может быть только на вашем IUnitOfWork). В этом случае вы должны ввести IUnitOfWork или просто ввести версию IUnitOfWork, которая имеет только метод сохранения (например, как IDataSaver).
Это упрощает уход за вашим контроллером, потому что вы можете видеть из конструктора, какие области приложения используются вашим контроллером (в вашем случае только один репозиторий).
В моем приложении много логики, похожей на транзакцию, которая реализуется unitOfWork. это подсказывает мне ввести IUnitOfWork вместо ICustomerRepository :)
Вообще говоря, шаблон UOW используется с контейнером DI. Какой контейнер вы используете?