Serviços da Web – WCF vs. ASMX (“Padrão”)

Eu estou trabalhando em um novo projeto. Existe algum benefício em ir com um serviço da Web WCF em um serviço web antigo e regular?

O Visual Studio oferece modelos para ambos. Quais são as diferenças? Prós e contras?

O que é um “serviço web antiquado regular?” Um serviço ASMX, ou você está usando o WSE também? Os serviços ASMX não são naturalmente interoperáveis, não suportam especificações WS- * e o ASMX é uma tecnologia que está envelhecendo muito rapidamente. Os serviços do WSE (Web Service Enhancements) acrescentam suporte ao WS- * e podem ser feitos para serem interoperáveis, mas o WCF foi criado para replace o WSE, portanto, você deve dedicar um tempo para aprendê-lo. Eu diria que, a menos que sua aplicação seja rápida e suja, você ganhará imensa flexibilidade e terminará com um design melhor se escolher o WCF. O WCF tem uma curva de aprendizado além do atributo [WebMethod], mas a curva de aprendizado é exagerada na minha opinião, e é exponencialmente mais poderosa e prova do futuro do que os serviços legados do ASMX.

A menos que sua linha do tempo simplesmente não possa tolerar a curva de aprendizado, você estaria fazendo um favor enorme ao aprender o WCF em vez de ficar apenas com o ASP.NET Web Services. As aplicações continuarão a se tornar cada vez mais distribuídas e interconectadas, e o WCF é o futuro da computação distribuída na plataforma Microsoft.

Aqui está uma comparação entre os dois.

Os profissionais de fazer tudo por si são:

  • Nenhuma curva de aprendizado
  • Muito flexível

Os profissionais do WCF são:

  • Custa menos tempo a longo prazo
  • Protocolos de comutação sem programação

Uma desvantagem do WCF: alguns nomes de propriedade estáticos podem ser muito longos …

Resumindo: o WCF permite que você se concentre na programação, mas precisa aprender primeiro 😉

Pro para WCF: Você não precisa de um servidor web (ou seja, IIS). Você realmente não precisa de um sistema operacional de servidor.

Eu gosto do fato de escrever serviços WCF facilita separar seu serviço da implementação. Você pode gravar seu serviço e hospedá-lo no IIS, em um aplicativo de console ou em um serviço do Windows; você também pode falar com ele via HTTP, net TCP, etc.

Testes unitários sobre a implicação e interação dos seus serviços são mais fáceis de fazer!

Se o seu projeto estiver usando o framework 4.0, por que não tente o WebApi, que é fácil de entender e usa a convenção sobre a configuração.

É uma ótima maneira de construir aplicativos com interfaces super rápidas

Veja os vídeos iniciados no MS, Ele evoluiu dos serviços de dados do WCF.

http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api

Em minha experiência

WCF

É absurdamente detalhado trabalhar com ele, não é totalmente compatível com outros produtos da Microsoft e, é claro, não é amplamente aceito fora do mundo da Microsoft.

Mas meu principal problema é que ele não é estável, ele tende a falhar (em algumas situações) e requer ajustá-lo antes que ele possa ser usado.

Em vez de

SOAP (também conhecido como Webservice padrão), funciona, é fácil de trabalhar e é amplamente compatível (o Java-JAX o aceita sem nenhuma modificação).

Para adicionar autenticação no SOAP pode ser um pouco complicado, mas não impossível.