Является ли антипаттерн вызовом услуг WEBAPI от контроллеров MVC?

Если было решено использовать WebAPI для создания уровня сервиса, который будет использоваться для разных клиентов. Какой был бы лучший способ архитектовать веб-клиент?

Поскольку WebAPI является дружественным к веб-интерфейсу, можно будет использовать его непосредственно у клиента с помощью javascript. Однако я бы волновался, что это может стать беспорядочным довольно быстро, а javascript - это не самая простая технология для unit test.

Альтернативой может быть использование класса HttpClient для вызова служб REST с контроллеров MVC. Является ли этот подход действительным?

Я полагаю, что оба подхода выше могут быть объединены, но я буду волноваться, что это будет беспорядочно. Согласитесь ли вы, что было бы лучше пойти с одним или другим подходом?

Извините, я видел много сообщений о том, следует ли использовать WebAPI или MVC, но ни один из них не комбинирует их.

Мысли?

ОТВЕТЫ

Ответ 1

Альтернативой может быть использование класса HttpClient для вызова REST услуг от контроллеров MVC. Является ли этот подход действительным?

Да, абсолютно. Просто, чтобы этот код не был помещен в ваши контроллеры, а скорее в ваш слой DAL, потому что контроллеры не должны знать, откуда поступают данные (плоский файл, база данных, веб-API,...).

Итак, существует 2 подхода:

  • Вы решили использовать свой веб-API из своего клиентского приложения MVC с использованием протокола HTTP. В этом случае вы создаете реализацию для своего репозитория (слой DAL), который будет использовать HTTP-клиент и возвращать непосредственно модели домена
  • Вы решили напрямую использовать сервисы, содержащиеся в этом веб-API, без отправки HTTP-запросов. В этом случае вы ссылаетесь на сборку, содержащую уровень сервиса для вашего веб-API в клиентском приложении MVC, и непосредственно эта сборка становится уровнем обслуживания для вашего приложения MVC. В этом случае веб-API через HTTP служит для других клиентов: javascript, mobile,...

Какой подход вы выберете, действительно зависит от вашего конкретного сценария и требований. Вам нужно поддерживать совместимые клиенты, отличные от вашего клиентского приложения MVC? В любом случае начните с определения уровня обслуживания в отдельной сборке, содержащей ваши модели домена и прочее. Затем вы всегда можете открыть этот уровень сервиса через веб-API (или службу WCF или что-то еще) или напрямую ссылаться на него с .NET-клиентов.

Ответ 2

Я думаю, у вас есть проект MVC, и вы пытаетесь отделить операции api от проекта MVC в отдельный проект веб-api? Если в этом случае вам нужно взвесить преимущества перед прыжком и создать отдельный сервисный проект.

После создания отдельного веб-проекта api вы не сможете легко использовать методы обслуживания прямо из javascript в своем проекте MVC из-за междоменного барьера (конечно, есть JSONP и CORS, но они не делают так, чтобы легко), поэтому вам нужно полагаться на класс HttpClient, создающий ненужные методы-оболочки в ваших контроллерах для связи с сервисом.

Стоит подумать о том, есть ли атрибут api в том же проекте MVC, когда у вас есть представления, которым нужны данные, предоставленные вашими методами api, но только вы должны использовать ApiController вместо Controller.