ASP.NET MVC, использующий WCF

Question

Мои контроллеры ASP.NET MVC 2 в настоящее время создают экземпляры сервисных объектов в своих конструкторах, передавая экземпляры репозитория, которые создаются Castle Windsor. У меня есть модульные тесты, которые вызывают действия контроллера после передачи экземпляров Moq репозиториев в конструктор контроллера.

Я хочу разрешить стороннему пользовательскому интерфейсу получать доступ к этим объектам службы через WCF.

Мне пришло в голову, что преобразование моего существующего сервисного уровня в веб-сервисы или даже добавление нового уровня веб-сервисов между пользовательским интерфейсом и существующим сервисным слоем нарушит мои модульные тесты, если я не найду способ преодолеть этот разрыв.

Я пытался найти решение, в котором мой пользовательский интерфейс был закодирован для интерфейса уровня обслуживания (он уже есть), и я мог бы использовать DI для передачи реализации веб-службы во время выполнения и передачи существующей реализации во время модуля. тестирование. Внедрение Web-сервиса просто вызвало бы существующую реализацию.

Вопросы:

1. Является ли такой подход целесообразным / возможным?
2. Есть ли примеры в учебном проекте или проекте с открытым исходным кодом?

EDIT:

Я полагаю, что теперь у меня есть работоспособное решение благодаря предложениям ниже. Я создал приложение службы WCF, которое использует существующие интерфейсы служб из моей модели домена. Реализация WCF - это класс, в котором конструктор берет экземпляры репозитория из Ninject расширение WCF и создает экземпляр службы из модели домена. Каждый метод / функция в WCF просто вызывает один и тот же метод / функцию из существующего уровня обслуживания.

Были некоторые предостережения. Например, я больше не могу передавать ссылку на мой ASP.NET MVC ModelState при создании службы в контроллере (на самом деле я использую Ninject, чтобы создать экземпляр службы WCF и передать его конструктору контроллера). Причина в том, что WCF является платформой обмена сообщениями - об изменениях необходимо явно сообщать обратно при каждом вызове (т. Е. Мои ошибки проверки теперь передаются обратно в качестве ссылочных параметров для отдельных функций / методов).

Мне также пришлось добавить некоторые ссылки на сериализацию / сервисную модель для моего бывшего проекта POCO Core.

Кроме того, я переключился с Касла на Ninject, потому что Решение WCF Касла имеет низкий уровень зрелости, и мне было неудобно использовать его в это время.

Answer 1

Ознакомьтесь с фабрикой программного обеспечения для веб-сервисов , созданной командой Patterns & Practices.Это хороший способ структурировать ваши услуги в контрактные проекты (данные, сообщения, услуги) и «бизнес-код».Как только вы лучше поймете, как структурировать ваш код, вы можете изменить их стиль на более подходящий вам.Их пример имеет тенденцию разделять все на множество проектов VS, что может быть немного излишним для большинства магазинов.Например, я не вижу много магазинов, разделяющих контракты данных между проектами.Да, в идеальном мире вам, вероятно, следует использовать много разных типов (например, адреса) в разных проектах, но я не вижу, чтобы это делалось очень часто.Итак, я стараюсь все свои контрактные вещи в одном проекте VS.

Answer 2

Если ваши сервисы уже определены как интерфейсы, тогда у вас есть преимущество.

Передайте сервисы в контроллеры как зависимости конструктора, а не как репозитории.Пусть ваш DI-контейнер A) предоставит репозитории для сервисов, и B) предоставит сервисы контроллерам.

Если вы хотите поднять свой сервисный уровень как сервисы wcf, к которым будут обращаться другие приложения, вы 'Я захочу использовать фабрику сервисов wcf для извлечения конкретных реализаций сервиса из вашего контейнера DI. Вот пример с windsor , должно быть легко адаптироваться к тому контейнеру, который вы используете.

На этом этапе вы можете изменить свой веб-сайт либо на А), либо продолжать вызывать службы напрямую, либоБ) Попросить их перезвонить на веб-сервисы с помощью сервисных клиентов.У обоих методов есть свои плюсы и минусы.

Answer 3

Можете ли вы объяснить более подробно, почему ваши тесты не работают?

Я все время занимаюсь этим типом разработки.Службы как классы => Службы как службы WCF.

Ваши тесты не должны нарушаться.Услуга WCF - это почти 100% контракт, базовый бизнес-код и логика не должны изменяться.