Мои контроллеры ASP.NET MVC 2 в настоящее время создают объекты службы в своих конструкторах, передавая экземпляры репозитория, созданные Castle Windsor. У меня есть модульные тесты, которые вызывают действия контроллера после передачи экземпляров репозиториев Moq конструктору контроллера.
Я хочу разрешить стороннему пользовательскому интерфейсу получать доступ к этим объектам службы через WCF.
Мне пришло в голову, что преобразование моего существующего слоя службы в веб-службы или даже добавление нового уровня веб-службы между пользовательским интерфейсом и существующим слоем службы нарушит мои модульные тесты, если я не найду способ преодолеть этот разрыв.
Я пытался разработать решение, в котором мой пользовательский интерфейс был закодирован в соответствии с интерфейсом сервисного уровня (это уже есть), и я мог использовать DI для передачи реализации веб-службы во время выполнения и передачи существующей реализации во время модульного тестирования. Внедрение Web-сервиса будет просто вызывать существующую реализацию.
Вопросы:
- Целесообразен/возможен ли такой подход?
- Есть ли примеры этого в учебнике или проекте с открытым исходным кодом?
ИЗМЕНИТЬ:
Я считаю, что теперь у меня есть работоспособное решение благодаря приведенным ниже предложениям. Я создал приложение службы WCF, которое использует существующие интерфейсы службы из моей модели предметной области. Реализация WCF — это класс, в котором конструктор берет экземпляры репозитория из Ninject в расширение WCF и создает экземпляр службы из модели предметной области. Каждый метод/функция в WCF просто вызывает один и тот же метод/функцию из существующего сервисного уровня.
Были некоторые предостережения. Например, я больше не могу передавать ссылку на мой ASP.NET MVC ModelState при создании службы в контроллере (на самом деле я использую Ninject для создания экземпляра службы WCF и предоставления его конструктору контроллера). Причина в том, что WCF является платформой обмена сообщениями - изменения должны быть явно переданы обратно при каждом вызове (т.е. мои ошибки проверки теперь передаются обратно как ссылочные параметры для отдельных функций/методов).
Мне также пришлось добавить некоторые ссылки на сериализацию/модель обслуживания в мой бывший проект POCO Core.
Кроме того, я переключился с Castle на Ninject, потому что WCF-решение Castle низкий уровень зрелости, и мне было неудобно использовать это в то время.
