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

Question

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

Answer 1

Мы только что закончили совершенно новый проект, используя WCF вместо ASMX Web Services в первый раз. Мы ОЧЕНЬ довольны результатами, но знаем, что была крутая кривая обучения. Тем не менее, мы чрезвычайно довольны общими результатами и знаем, что это основа для всего, что Microsoft делает в будущем, и оно того стоило: бородавки и все такое.

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

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

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

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

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

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

Answer 2

ASMX великолепен и прост - но он очень ограничен во многих отношениях:

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

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

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

Что касается ресурсов: есть MSDN WCF Developer Center , в котором есть все - от учебников для начинающих до статей и примеров кода.

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

Answer 3

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

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

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

Answer 4

При использовании 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 Services; они нацелены на поддержку AJAX, а также Silverlight, и это автоматизирует большую часть конфигурации WCF.

Answer 5

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

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

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

Answer 6

Есть несколько моментов, на которые следует обратить внимание, прежде чем перейти к WCF:

1. WCF архитектурно более устойчив и продвигает лучшие практики.
2. Если вы знаете, что делаете, это «шелковисто гладко», если вы не ездить.
3. Достаточно ли у вас времени для завершения конвертации ваших услуг?

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