Подтвердить что ты не робот

Что выбрать? Веб-сервис ASMX или WCF в .net 3.5?

В текущем проекте, над которым я работаю, широко используется веб-службы и выполняется в .net 3.5. Теперь, когда мы собираемся реализовать вторую фазу, мы смущены, если мы должны использовать WCF или веб-сервис, как это было сделано ранее? Кроме того, есть что-то новое, что может быть полезно и подходит к .net 4.0 для веб-служб или WCF.

4b9b3361

Ответ 1

Мы только что закончили новый проект с использованием WCF вместо ASMX Web Services в первый раз. Мы очень довольны результатами, но знаем, что была крутая кривая обучения. Тем не менее, мы очень довольны результатами и понимаем, что это основа для всего, что делает Microsoft в будущем, и это полностью стоит боль - бородавки и все.

Быстрые преимущества, которые мы получили от ASMX:

1) Для внутренних вызовов (за брандмауэром) между службами мы используем привязку net: tcp, которая намного быстрее, чем SOAP

2) Мы включили как конечную точку net: tcp, так и конечную точку "web" в той же службе только с обновлением файла конфигурации (никаких изменений кода)

3) Мы смогли создать поддерживающие AJAX веб-сервисы RESTful только с изменениями конфигурации и с использованием уже встроенного DataContractJsonSerializer. Для этого нам пришлось бы писать HTTP-обработчик (ashx) и обрабатывать большую часть сериализация Json и анализ URL вручную.

4) Поскольку наш сайт нуждается в масштабировании для оптимизации производительности и стабильности, мы рассматриваем преобразование к использованию структуры обмена сообщениями на основе MSMQ, которая является асинхронной и гарантированной и участвует в транзакциях; WCF обеспечивает привязку MSMQ, которая требует малое изменение кода в наших сервисах, - просто ссылку на обновления и правильную настройку MSMQ с существующими службами (и добавление атрибутов для границ транзакции).

НО БУДЬ ПРЕДУПРЕЖДЕН: Действительно инвестируйте в изучение этого (купите синюю книгу O-Reily и пройдите через нее). Во время разработки есть такие вещи, как изменения имени-аргумента, которые фактически не нарушают ссылки на службы, но приводят к передаче нулевых аргументов (встроенная обработка перекоса версии), модели хостинга (Windows Service vs. IIS) и создание экземпляров модели и FaultExceptions для всех ДЕЙСТВИТЕЛЬНО понять. Мы не пошли, и у нас были некоторые боли. Но мы пахали вперед и очень довольны нашими знаниями и возможностями гибкости и роста, с которыми мы больше не привязаны к ASMX!

Ответ 2

ASMX велик и прост - но он очень ограничен по-разному:

  • вы можете размещать только ваши веб-службы в IIS
  • вы можете использовать только ваши веб-службы через HTTP
  • Безопасность очень ограничена.

WCF исправляет это - и предлагает гораздо больше этого. Вы можете разместить свои службы WCF в IIS - или сам хост в консольном приложении или службе Win NT, по мере необходимости. Вы можете подключать свои службы WCF с использованием протоколов HTTP, TCP/IP, MSMQ, одноранговых протоколов, именованных каналов для связи на машине и многое другое.

Я бы определенно рекомендовал работать с WCF. Это немного сложнее, чем ASMX, но также предлагает намного больше возможностей и возможностей!

Что касается resoures: там Центр разработчиков MSDN WCF, в котором есть все, начиная от новичков и заканчивая статьями и образцом кода.

Кроме того, я бы порекомендовал вам взглянуть на экран Pluralsight на WCF - это отличная серия, идущая от " Создание вашей первой службы WCF" и " Создание вашего первого клиента WCF" все путь к довольно продвинутым темам. Аарон Сконнард очень хорошо объясняет все в 10-15 минутах скринкастов - очень рекомендуется!

Ответ 3

Модель WCF значительно более гибкая, по существу - если вы только используете ее для представления базовой модели http с использованием базового профиля и xml с прокси-объектами - он будет очень похож.

Краткий список различий:

  • намного лучше поддерживать новые стандарты (хотя WSE2 и WSE3 доступны для asmx, в WCF это намного проще).
  • Встроенный MTOM (и исправляет известную ошибку, которую я помню, находясь в WSE3 с помощью MTOM)
  • гораздо более широкий диапазон поддерживаемых транспортов/протоколов и т.д., а поведение полностью настраивается/расширяемо; например, позволяя вам использовать пользовательский сериализатор/протокол/транспорт/и т.д., без изменений, просто изменив конфигурацию
  • гораздо более богатая конфигурация, как в конфигурации, так и во время выполнения
  • полная поддержка инспекторов и заказчиков.
  • возможность совместного использования объектных моделей, если вы хотите
  • вы можете разместить его за пределами веб-сервера; консоль exe или служба, например

Ответ 4

Перед переходом на WCF нужно рассмотреть разные моменты:

  • WCF является архитектурно более надежным и продвигает лучшие практики.
  • Если вы знаете, что делаете "шелковистые гладкие", если вы не используете езды.
  • У вас есть достаточно времени для завершения преобразования ваших услуг?

Наконец, я бы сказал, что если у вас есть время, bling и мышцы сделать обновление. Это стоит того. Если asmx удовлетворяет все потребности, вы можете сохранить веб-службы.

Ответ 5

Два следующих аспекта:

  • Независимо от того, как вы это решаете для серверной части, вы можете легко использовать Webservices и службы WCF, используя только WCF на стороне клиента. Это имеет значение, если вы используете несколько сервисов с одним клиентом.

  • Вы задали вопрос о предстоящих тем. Если вы рассматриваете Cloud Computing: можно разместить службы WCF на Windows Azure.

Ответ 6

С WCF или ASMX убедитесь, что вы добавляете свои услуги на свои страницы, используя тег asp: ScriptManager. Он будет создавать для вас JavaScript-прокси, и преимущество заключается в том, что вам не нужно создавать какие-либо синтаксические разборки вообще, независимо от базового протокола. Это очень, очень приятно. Этот пример - ASMX, но каждый бит такой же чистый, как и WCF.

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Services>
        <asp:ServiceReference Path="~/WebServices/Admin/HospitalLocationService.asmx" InlineScript="true" />
    </Services>
</asp:ScriptManager>

Кроме того, вы можете заставить ASMX отправить JSON, добавив атрибуты ScriptService и ScriptMethod:

<System.Web.Services.WebService(Namespace:="http://www.fujimed.com/")> _
<System.Web.Services.WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _
<ToolboxItem(False)> _
<ScriptService()> _
Public Class HospitalLocationService
    Inherits System.Web.Services.WebService

    <WebMethod()> _
    <ScriptMethod()> _
    Public Function GetAll() As List(Of HospitalLocationEntity)
        Return (New HospitalLocation()).GetAll().Data
    End Function

    <WebMethod()> _
    <ScriptMethod()> _
    Public Function GetByID(ByVal ID As Integer) As HospitalLocationEntity
        Return (New HospitalLocation()).GetHospitalLocation(ID).Data
    End Function

End Class

Использование службы без разбора (это то, что делает ScriptManager для вас):

 function editLocation(id) {
    vRIS.HospitalLocationService.GetByID(id, getComplete, getError);
 }

 function getComplete(results, context, methodName) {
    document.all['txtLocation'].value = results.Location;
    document.all['txtInterfaceID'].value = results.InterfaceID;
    document.all['selActive'].value = results.Active ? "true" : "false";
    document.all['hdnLocationID'].value = results.ID.toString();
 }

 function getError(errorInfo, context, methodName) {
    Alert(methodName + " : " + errorInfo);
    document.all['txtLocation'].value = "";
    document.all['txtInterfaceID'].value = "";
    document.all['selActive'].value = "false";
    document.all['hdnLocationID'].value = "";
 }

Отредактировано для добавления: со всем вышеизложенным на основе ASMX я по-прежнему оставил WCF, для универсальности и для возможности определять контракты данных. Также изучите службы WCF RIA; они нацелены на поддержку AJAX, а также Silverlight и автоматизируют большую часть конфигурации WCF.