ASP.NET MVC против WCF для REST API + использование веб-страницы

Я думаю, что дискуссия о программном использовании, ориентированном на обслуживание, против взаимодействия с человеком очевидна.

Но если бы я создал приложение, которое использует как программный API, так и веб-сайт, который использует данные, связанные с одним и тем же API, то склоняется ли оно в пользу использования только ASP.NET?

Насколько легко интегрировать ASP.NET и WCF для работы в одном приложении?

— Xster
источник

Что касается написания одного приложения, которое использует как ASP.NET/MVC, так и WCF, это не очень хорошо. WebAPI, возможно, улучшил ситуацию, но в одном проекте, с которым я знаком, он использовал WCF и MVC в одном приложении, в итоге они поддержали два разных набора моделей для представления одних и тех же концепций - один для кода WCF и один для MVC. код. Вы можете представить себе все средства отображения, которые они должны были написать, чтобы перевести вещи между двумя моделями - там было много строк кода, которых можно было бы / нужно было избежать.

Отчасти это произошло потому, что объекты запросов и ответов WCF должны быть аннотированы с помощью [DataContract], а их свойства - с помощью [DataMember], тогда как MVC этого не требует. Идиоматический MVC, с другой стороны, будет нуждаться в ViewModels, которые имеют другие цели, чем WCF DataContracts. Конечно, возможно, что использование двух полных наборов доменных объектов было больше связано с законом Конвея, чем с конфликтом WCF и MVC, но стоит отметить, что WCF и MVC имеют разные цели и требования в отношении вывода и ввода.

Лично я неравнодушен к разработке простого, но мощного сервисно-ориентированного серверного API, особенно когда вам может понадобиться несколько клиентов. Я думаю, что появление превосходных JavaScript MVVM и микро-MVC фреймворков делает это естественным выбором, так как написание кода приложения с использованием BackboneJS , KnockoutJS и других позволяет создать эффективную среду разработки. Затем вы можете использовать серверную часть в микро MVC по вашему выбору для создания веб-приложения или на мобильном клиенте, и ваши партнеры могут также использовать тот же API удаленно.

Предложение

Либо WebAPI, либо Service Stack могут быть хорошими кандидатами для создания вашего внутреннего API. Я рекомендую Service Stack, так как использую его последние несколько месяцев и считаю, что он является отличной заменой WCF. В настоящее время я пишу серию руководств по стеку сервисов в своем блоге .

Стек обслуживания групп поддержки опубликовал пример приложения, использующего инфраструктуру для разработки клона, подобного StackOverflow, который демонстрирует шаблон разработки, который, на мой взгляд, особенно убедителен. Он включает в себя простой, основанный на моделях сервис, который вы можете себе представить, как его используют веб-сайт MVC, мобильное приложение или что-то еще. Цели разработки ServiceStack явно поддерживают шаблон, который должен привести к меньшей связи между клиентом и сервером. Идея состоит в том, чтобы избегать болтливых API с вызовами, как GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)в пользу меньшего количества методов. Вы можете реализовать то же самое в стеке сервисов следующим образом:

[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers 
{
    public int? RegionId { get; set; }
    public string SearchTerm { get; set; }
}

public class CustomersService : Service
{
    public object Get(Customers request) {
        // handle request
        return new CustomersResponse();
    }
}

Выгода, в моих глазах, является то , что вместо того , чтобы ваш бизнес - логики распространения над большим и большим количеством отдельных методов GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), все это в одном месте. Это должно привести к большему количеству поддерживаемого кода.

По совпадению, Stack Exchange нанял первоначального автора Service Stack . Он продолжает активно участвовать в проекте Service Stack.

Я особенно люблю очереди сообщений для определенных вещей - и хотя WCF допускает это, WebAPI нет. ServiceStack позволяет вызывать один и тот же веб-сервис через MQ. Для получения дополнительной информации об этом см. Redis MQ Host по адресу: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis

— Кайл Ходжсон
источник

Примечание. ServiceStack разрешает запуск одной и той же веб-службы через MQ, см. Узел Redis MQ по адресу: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis

— mythz,

Отлично, спасибо @mythz! Я этого не знал.

— Кайл Ходжсон

но кажется, что mvc4 идет по пути веб-API ... разве это не делает его "официально спонсируемым" фреймворком?

— Xster

После борьбы с «официально спонсируемой структурой» (WCF pre WebAPI) в течение последних двух лет, это больше не является частью моих критериев отбора. Это не значит, что WebAPI хорош или плох, я еще не пробовал. Я не чувствовал никакого желания, ServiceStack решает мои проблемы.

— Кайл Ходжсон

Здесь очевидно, что ViewModels и объекты ответа от служб WCF - это две совершенно разные вещи. ViewModel может быть только подмножеством данных или кусками данных из разных источников вместе взятых. Наличие другого набора объектов для ViewModels - это именно то, что нужно для MVC, откуда данные (из WCF или иным образом) не имеют значения. Кроме того, существует Automapper для отображения типов объектов для сохранения всего этого стандартного кода X.Name = Y.Name.

— Оз

@tzerb ответил правильно, IMO, но я хотел бы расширить этот ответ. ASP.NET Web API, который в настоящее время находится на стадии бета-тестирования, и проект OSS - самая близкая среда, которую вы ищете.

Краткое описание продукта следующее (приведено на странице ASP.NET Web API ):

ASP.NET Web API - это инфраструктура, которая позволяет легко создавать HTTP-сервисы для широкого круга клиентов, включая браузеры и мобильные устройства. ASP.NET Web API является идеальной платформой для создания приложений RESTful в .NET Framework.

Что касается клиентского приложения, которое вы, возможно, используете для использования своего веб-API, оно, безусловно, не обязательно должно быть приложением ASP.NET. Вы можете использовать свой API со статической HTML-страницей, используя JavaScript. Вы можете легко это сделать с помощью некоторых полезных библиотек JavaScript, таких как jQuery.

С другой стороны, вы можете использовать свой API на сайте сервера в любом приложении ASP.NET. Проект Web API также представил новый клиентский API-интерфейс HTTP .NET под названием HttpClient, который упрощает использование HTTP-сервисов.

В общем, вот хороший набор ресурсов для начала:

Начало работы с ASP.NET Web API - учебные пособия, видео, примеры

Помните, что проект все еще находится в стадии бета-тестирования. Я рекомендую вам следить за блогом Хенрика Ф. Нильсена, где он публикует информацию о последних неизданных обновлениях проекта. Вы можете обратиться к исходному коду проекта и процессу разработки внутри проекта ASP.NET Web Stack .

— tugberk
источник

Я думаю, что в настоящее время предполагается использовать MVC Web API вместо WCF для REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx

Модель разработки довольно близка, и вы обходите иногда неприятную конфигурацию WCF.

— tzerb
источник