Como gerencio o debate técnico sobre WCF versus API da Web?
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Estou gerenciando uma equipe de 15 desenvolvedores agora, e estamos presos em um ponto na escolha da tecnologia, onde a equipe é dividida em duas equipes completamente opostas, debatendo sobre o uso de WCF versus API da Web.
A equipe A, que oferece suporte ao uso da API da Web, apresenta os seguintes motivos:
- A API da Web é apenas a maneira moderna de escrever serviços (Wikipédia)
- WCF é uma sobrecarga para HTTP.É uma solução para TCP, e Net Pipes e outros protocolos
- Os modelos WCF não são POCO, por causa de [DataContract] e [DataMember] e esses atributos
- SOAP não é tão legível e prático quanto JSON
- SOAP é uma sobrecarga para a rede em comparação com JSON (transporte sobre HTTP)
- Sem sobrecarga de métodos
A equipe B, que suporta o uso do WCF, diz:
- O WCF suporta vários protocolos (via configuração)
- WCF suporta transações distribuídas
- Existem muitos bons exemplos e histórias de sucesso para o WCF (enquanto a API da Web ainda é jovem)
- Duplex é excelente para comunicação bidirecional
Este debate continua e não sei o que fazer agora.Pessoalmente, acho que devemos usar uma ferramenta apenas para o local correto de uso .Em outras palavras, é melhor usar a API da Web, se quisermos expor um serviço por HTTP, mas usar WCF quando se trata de TCP e Duplex.
Ao pesquisar na Internet, não podemos chegar a um resultado sólido.Existem muitas postagens para apoiar o WCF, mas, pelo contrário, também encontramos reclamações de pessoas sobre isso.Eu sei que a natureza desta questão pode parecer discutível, mas precisamos de algumas boas dicas para decidir.Estamos presos em um ponto em que escolher uma tecnologia por acaso pode nos fazer arrepender mais tarde.Queremos escolher com os olhos abertos.
Nosso uso seria principalmente para web e exporíamos nossos serviços por HTTP.Em alguns casos (digamos, 5 a 10 por cento), podemos precisar de transações distribuídas.
O que eu deveria fazer agora?Como posso gerir este debate de forma construtiva?
Solução
Quando ambos os lados têm bons argumentos e as opiniões sobre o assunto são fortes demais para chegar a um consenso, você, como gerente, precisa tomar uma decisão e encerrar o debate.Caso contrário, ele apenas girará em círculos e fortalecerá ainda mais as posições de todos os participantes.Quanto mais você esperar, mais difícil será para o lado "perdedor" admitir a derrota e trabalhar produtivamente com o resultado.
Anote todos os argumentos, valorize sua importância para o projeto e tome sua decisão.Quando não puder, jogue uma moeda.Seu projeto provavelmente pode ser concluído com sucesso com qualquer uma das tecnologias, e desperdiçar um tempo valioso com debates desnecessários custará dinheiro desnecessário.
Outras dicas
Supondo que ambos os lados estejam 100% corretos em todos os seus argumentos, quais importam?
Os modelos WCF não são POCO, por causa de [DataContract] e [DataMember] e esses atributos
Você se importa?Você está planejando fazer algo que requer POCO?
WCF suporta transações distribuídas
Novamente, isso é algo que você vai usar e precisa construir se não o tiver porque tomou o outro caminho?
Basicamente chegar ao coração de qual:
- Oferece tudo o que você precisa (se nem oferece tudo o que você precisa, o que faz com que você tenha que fazer o mínimo de trabalho).
- Oferece a menor quantidade de lixo que você não vai usar, mas tem que aturar de qualquer maneira.
Qualquer argumento apresentado que não esteja no caminho do que você precisa realizar é irrelevante e não deve ser levado em consideração na sua decisão, com alguma margem de manobra para considerar a expansão futura.
Coloque meus dois centavos.
Como gerente, você deve pedir aos seus companheiros de equipe que tenham em mente o Princípio Yagni. Isso ajudará a reduzir a lista de motivos apresentados por ambas as equipes.
Nosso uso seria principalmente para web e exporíamos nossos serviços por HTTP.Em alguns casos (digamos, 5 a 10 por cento), podemos precisar de transações distribuídas.
Em vez de mergulhar na transação distribuída, você deve considerar trabalhar com compensação.
A última coisa a ter em conta é a curva de aprendizagem.Dependendo do prazo do seu projeto, como gerente, você deve ser capaz de decidir se está certo começar a aprender uma nova tecnologia ou não.
Se você tiver muito tempo a perder, vá para algum tipo de Dia da Inovação, onde as equipes A e B teriam um dia para produzir provas de conceitos com base nos mesmos requisitos.
A propósito, para o cara que diz " modelos WCF não são POCO, por causa de [DataContract] & [DataMember] e esses atributos ", diga a ele que POCOs geralmente são entidades de domínio e que não é uma prática recomendada exporseu objeto de domínio para qualquer tipo de cliente, é para isso que servem os DTOs.
O que eu deveria fazer agora?Como posso gerir este debate de forma construtiva?
Primeiro, mantenha a subjetividade afastada.Nos argumentos da sua equipe WebAPI, acho que "Web API é apenas a maneira moderna" *, "modelos WCF não são POCO, por causa desses atributos" e "SOAP não é tão legível e útil quanto JSON" bastante opinativo, se não totalmente errado, e não vai ajudar a tomar uma decisão.
Então, o que fazer: decida o que você quer fazer com seu(s) serviço(s) e, em seguida, escolha uma técnica que acomode esse objetivo e sua manutenção e extensibilidade com o mínimo de dor.Você pode fazer isso simplesmente pesquisando se algum aspecto é suportado pela estrutura a ser usada.
Material de leitura interessante:
*: observe que você se refere à Wikipedia para isso, onde a citação é: " Aplicativos da Web da Web 2.0 se afastaram de uma arquitetura orientada a serviços (SOA) com serviços da Web baseados em SOAP para coleções mais coesas de recursos da Web RESTful" .Esse é um exemplo de uso para quando seu serviço deve ser consumido de uma página da web.Isso também pode ser feito facilmente com o WCF, usando o WebHttpBinding.Não diz "Use WebAPI para isso" .
Se esta pergunta se estender além do "como gerenciar a discussão" : eu usaria o WCF se os serviços fossem consumidos por clientes não-web, porque seus metadados permitem a geração de clientes fortemente tipados surpreendentemente fáceis.
Gerenciamento de equipe à parte, você não escolhe um em detrimento do outro.Você precisa observar a finalidade de cada serviço da Web e usar a tecnologia apropriada para a parte específica do aplicativo.É como banir os procedimentos da loja quando a equipe está usando o framework de entidade.
Nosso uso seria principalmente para web e exporíamos nossos serviços por HTTP.Em alguns casos (digamos, 5 a 10 por cento), podemos precisar de transações distribuídas.
Em seguida, você escreve esses serviços da Web de 5 a 10% no WCF.Se o serviço for referenciado internamente em outros projetos, não há discussão.A vantagem da capacidade de importar o contrato WCF para criar o proxy do cliente NÃO está aberta para discussão.Leva toda a integração, eficiência e segurança de tipo a um nível totalmente novo.
Você escreve o que deve ser usado para solicitações públicas de API (talvez) / Ajax na API da Web Asp.net.
Se for apenas uma chamada ajax específica da página, você pode usar o Asp.Net MVC.
Não escolha, abrace todos eles.A API da Web WCF e Asp.net servem a propósitos diferentes.Ninguém diz que você não pode ter maçã e laranja na sua salada de frutas.Tentar escolher um sobre o outro e empurrá-lo para baixo em todos os cenários é pura preguiça.
Nossa equipe teve uma discussão semelhante há alguns meses.O fator decisivo para nós se resumia a como iríamos criar e implementar cada tecnologia.Como já estávamos construindo um aplicativo MVC e usando Knockout.js para vinculação de dados, estávamos efetivamente usando MVVM com os controladores sendo apenas uma API para dados.
Isso nos permitiu categorizar nosso uso das tecnologias com este projeto da seguinte forma:
- A API da Web seria usada como nossa API para chamadas knockout e Ajax, tornando-as nossos comandos para o padrão MVVM.Nossa lógica de negócios para o aplicativo da Web é encerrada por trás dessa camada por meio de várias classes, repositórios e fábricas.
- O WCF é então usado para nosso armazenamento de dados, expondo dados de nosso banco de dados não apenas para este site, mas também para qualquer outro site ou serviço que consumiu os dados expostos.
Embora isso possa não ser uma resposta popular ou hipertécnica, determinar o que você precisa primeiro e como ou se a tecnologia ajudará é o que ajudou minha equipe a decidir qual tecnologia usar e onde.
Em outras palavras, é melhor usar a API da Web, se quisermos expor um serviço por HTTP, mas usar WCF quando se trata de TCP e Duplex.
Essa seria a abordagem mais razoável.É bastante comum ter serviços WCF e WebApi no mesmo aplicativo da Web, onde ambos servem a propósitos diferentes.
Apenas para corrigir alguns argumentos:
Os modelos WCF não são POCO, por causa de [DataContract] e [DataMember] e esses atributos
Em muitos casos, os modelos WCF funcionam sem atributos datacontract/datamember.
SOAP não é tão legível e prático quanto JSON
Não é verdade, mas os serviços da Web WCF geralmente carregam XML simples em vez de SOAP inchado.Isso definitivamente é legível.
Um argumento para o WCF: se houver um WSDL disponível, existem várias ferramentas em quase todas as tecnologias que podem criar proxies a partir dos metadados.Por outro lado, o esquema JSON ainda não é amplamente suportado.
Por que não seguir a linha com o WCF Data Services?boas consultas e usabilidade no estilo OData/webapi com os poderes do WCF e a capacidade de retornar JSON muito bem.Além disso, o Wcf não é tão ruim se você tiver um bom código de hospedagem wcf automático como o seguinte:
https://github.com/ImaginaryDevelopment/MvcOdata
Eu diria que eles não estão muito separados, exceto que quando usamos WebApi no front-end e WCF data services na camada intermediária, o WebApi vomitou em coisas simples, como string contém ou operadores odata de correspondência de string.
Um bom arquiteto atrasa as decisões de tecnologia até que elas sejam absolutamente necessárias.
Em outras palavras, não tome a decisão até que um cliente precise realmente se conectar.Você pode construir uma camada de serviço totalmente testada sem realmente colocar um mecanismo de transporte/comunicação sobre ela.Mais de 95% do trabalho pode ser feito "abaixo" do adaptador, fora da estrutura.
Na hora de expor esses serviços a clientes remotos, você pode escolher a estrutura mais moderna da prateleira e escrever wrappers finos em uma camada de serviço versátil.
Inferno, se sua camada de serviço "real" for bem feita, você pode até tentar vários wrappers com um custo mínimo.
Essa é a resposta dogmática, de qualquer maneira.Na prática , você pode querer escolher a ferramenta mais simples da prateleira para facilitar os testes de integração iniciais e frequentes - mas, ainda assim, limite sua dependência dela e trate-a estritamente como uma camada de comunicação simples sobre os serviços reais .
Se você adotar essa abordagem, provavelmente descobrirá que escolhe a ferramenta mais simples para usar inicialmente e ninguém se incomodará , porque a equipe sabe que pode implementar uma ferramenta ou estrutura mais sofisticada ou moderna posteriormente, se necessário , com o mínimo de esforço.
Portanto, estou enfrentando a mesma escolha agora, me perguntei qual é o subconjunto de recursos do WCF que nossa equipe está usando no momento. Usamos protocolos diferentes?Não. Usamos suporte a transações?Não (embora usemos mecanismos personalizados de consistência eventual).Usamos duplex?Não.
Por que gostaríamos de usar a API da Web?Integração de front-end mais fácil (remove a camada de serviço adicional existente agora), SignalR para enviar resposta aos clientes, cache para GETs.
Pode ser, pode-se encontrar outras razões :) Além disso, razões para ficar com WCF.
Se eu estivesse no seu lugar, começaria examinando as habilidades de sua equipe.Se todos em sua equipe já conhecem o WCF e apenas uma pequena porcentagem conhece a API da Web, sua decisão já está tomada para você.
De qualquer forma, se você tiver tempo, invista em aprender e melhorar sua base de conhecimento, mas não às custas da necessidade de negócios e da produtividade da empresa.
Eu perguntaria que modelo de interação você precisa apoiar?Sua interface externa desejada se parece mais com RPC ou REST?Na minha experiência, geralmente está em algum lugar entre, mas principalmente um ou outro.
Você está consumindo seus próprios serviços para outros projetos em .Net?Esta é provavelmente a pergunta mais reveladora que você pode fazer.O WCF tem a vantagem de poder abstrair suas interfaces em uma biblioteca de classes separada e poder construir e injetar seu cliente.Como uma extensão para isso, você pode montar seu projeto baseado em WCF com terminais JSON e SOAP/WSDL, eu já fiz isso.O WCF também oferece melhores garantias em relação às interfaces definidas.
Dito isso, se você espera ter clientes de outras plataformas XML em geral, muito menos o SOAP tem uma sobrecarga mensurável além do que os terminais JSON simples têm.Se você seguir a rota JSON/Web API, precisará se tornar muito melhor em documentar como interagir com seus endpoints e API.
Em geral, sugiro escrever um documento de API simples que indique como você enviará dados e como deseja uma resposta para uma estrutura de objeto de solicitação única.Escreva seu caso de teste da maneira mais universal e documente-o como tal.Eu recomendaria uma simples declaração de curl.Em seguida, faça com que vários de seus membros implementem isso usando o WCF e com a API da Web.Então veja qual ganha.
Pessoalmente, apesar de ter feito alguns projetos e implementações relativamente grandes com o WCF, eu realmente me inclino para a implementação mais simples que na minha mente é o WCF direto com o uso de resultados JSON e algum comportamento de substituição no Global.asax.cs para lidar com condições de erro.Se a documentação de uma API inclui instruções curl e você pode exercitar toda a funcionalidade de sua API com exemplos de curl, fica muito mais fácil para os clientes serem implementados em qualquer linguagem que suporte interfaces da web.Este é realmente onde o WCF começa a cair.Ter uma API bem definida com documentação agnóstica é melhor do que ter estruturas com ferramentas automatizadas ao lidar com sistemas estrangeiros.Falando como consumidor desses sistemas de outras plataformas.
Uma coisa além disso, é implementar seu cliente em duas linguagens diferentes.Faça um cliente em C#, mas também faça um em Node.js ou Python e veja como eles realmente se encaixam.Esse exercício por si só ajudará você a acabar com as pontas soltas em sua API.
