Как передать другой объект репозитория с одним и тем же интерфейсом на мой сервисный уровень с помощью Ninject? - PullRequest
0 голосов
/ 13 февраля 2011

Итак, я столкнулся с этой путаницей в прошлом и обошел ее, просто не используя Ninject. Теперь, когда я переделываю свой сайт, я нахожусь в точке, где Ninject снова оказывается полезной, но я запутался. Опять .

У меня есть проект MVC3, использующий шаблон репозитория. В настоящее время мой Home Controller создает несколько объектов, таких как OrderRepository.cs, CustomerRepository.cs и отправляет их в сервисы OrderService.cs и CustomerService.cs. У меня есть тестовый проект, который я могу использовать для отправки в FakeOrderRepository.cs и FakeCustomerRepository.cs. Это удобно для модульного тестирования, когда я прохожу свой проект.

Однако я понимаю, что, объявив репозитории в моем контроллере и модульных тестах, я устанавливаю зависимость от этих объектов. То, что я хотел бы сделать, это не передавать репозитории, и чтобы мой уровень Service использовал Ninject, чтобы сказать: «О, смотри, IOrderRepository в моем конструкторе, я лучше пойду, получу OrderRepository».

Проблема, с которой я столкнулся в прошлый раз, заключается в том, что, хотя я могу связать OrderRepository с любым экземпляром или IOrderRepository в конструкторе и связать их вместе в моем Global.ascx, это, похоже, оставляет мои модульные тесты высокими и сухими. Если я не войду и не переключу каждую привязку в моем Global.ascx с объектом, который я хочу передать (в данном случае, FakeOrderRepository.cs) каждый раз, когда я запускаю тесты, мой реальный репозиторий будет передаваться. Как я могу получить свой тестовый проект и Controller передают разные репозитории при использовании одного и того же интерфейса IOrderRepository?

Вот так, длинное объяснение чего-то, что, вероятно, просто. У меня такое чувство, что я обдумываю это и просто упускаю несколько ключевых понятий.

tldr: Как я могу иметь конструктор на своем сервисном уровне и передавать объекты хранилища, отличающиеся от моих контроллеров и модульных тестов, используя Ninject.

Ответы [ 2 ]

1 голос
/ 14 февраля 2011
  1. Продолжайте максимально использовать инъекцию ctor, чтобы все объявляли свои зависимости и минимизировали обязанности

  2. Не используйте Ninject в своем тестеконтекст - это не должно быть необходимым - вы сделали это слишком сложным, если оказались в этом месте

  3. Если вы используете Ninject против ASP.NET MVC 3, вам следует с использованием стандартной интеграции

0 голосов
/ 13 февраля 2011

Имеет смысл использовать инжекцию конструктора в ваших классах обслуживания для внедрения репозиториев, и вы можете установить это из global.asax.

Чтобы ваши тесты работали, у вас есть несколько вариантов:

  1. Установите привязки к поддельным репозиториям в ваших тестах. Другими словами, создайте другой модуль / ядро ​​NInject в своем методе настройки теста. Если это всего лишь тесты контроллера, то привязки в global.asax не будут применяться, поэтому вам все равно придется установить альтернативные привязки или настроить зависимости вручную (это второй вариант).

  2. Используйте инжекцию конструктора, чтобы внедрить ваши классы обслуживания в контроллер и заставить NInject обрабатывать это во время выполнения, переопределяя фабрику контроллера. Затем в своих модульных тестах вы могли бы создавать свои классы обслуживания, подделывать репозитории вручную и передавать служебные объекты в контроллеры через их конструкторы.

Я нашел эту статью полезной, чтобы понять, как интегрировать NInject в проект MVC: http://msdn.microsoft.com/en-us/magazine/dd942838.aspx

...