Como gerencio o debate técnico sobre WCF vs. API da Web?

Quando ambos os lados têm bons argumentos e as opiniões sobre o assunto são muito strongs 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, então, tome sua decisão. Quando você não pode, jogue uma moeda. Seu projeto provavelmente pode ser concluído com sucesso com qualquer tecnologia, e desperdiçar tempo valioso com debates desnecessários só vai custar dinheiro desnecessário.

Assumindo que ambos os lados estão 100% corretos em todos os argumentos, quais deles são importantes?

WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes

Você se importa? Você está planejando fazer algo que requer POCO?

WCF supports distributed transactions

Novamente, é algo que você vai usar e precisa construir se não o tiver porque tomou o outro caminho?

Basicamente, chegue ao coração de qual:

• Oferece tudo o que você precisa (se nenhum dos dois oferecer tudo 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 precisa agüentar de qualquer maneira.

Qualquer argumento apresentado que não esteja no caminho do que você precisa realizar é irrelevante e não deve levar em consideração 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 colegas de equipe que tenham em mente o Princípio Yagni . Isso ajudará a reduzir a lista de motivos apresentados por ambas as equipes.

Our usage would be mostly for web, and we would expose our services over HTTP. In some cases (say 5 to 10 percent) we might need distributed transactions though.

Em vez de mergulhar em transações distribuídas, considere trabalhar com compensação .

A última coisa a considerar é a curva de aprendizado. Dependendo do prazo do seu projeto, como gerente, você deve ser capaz de decidir se está tudo bem em começar a aprender uma nova tecnologia ou não.

Se você tiver muito tempo para perder, faça um Dia de 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 que " modelos WCF não são POCO, por causa de [DataContract] & [DataMember] e aqueles atributos ", diga a ele que POCOs geralmente são entidades de domínio e que não é uma prática recomendada expor seu objeto de domínio a qualquer tipo de cliente, é para isso que os DTOs são.

What should I do now? How do I manage this debate in a constructive way?

Primeiro, mantenha a subjetividade distante. Nos argumentos da sua equipe WebAPI, eu encontro "API da Web é apenas a maneira moderna" *, "modelos WCF não são POCO, por causa desses atributos" e " O SOAP não é tão legível e prático quanto o JSON " muito opinativo, se não totalmente errado, e não ajudará a tomar uma decisão.

Então, o que fazer: decida o que você quer fazer com seu (s) serviço (s) , então escolha uma técnica que acomode essa meta e sua capacidade de manutenção e extensibilidade com o mínimo de dor. Você pode fazer isso simplesmente pesquisando se um determinado aspecto é suportado pela estrutura a ser usada.

Material de leitura interessante:

• Mvc 4 versus Wcf Web Api
• APIs da Web do ASP.NET ou do WCF? Meus dois centavos no assunto
• WebAPI ou WCF?

*: note que você se refere à Wikipedia para isso, onde a citação é: " aplicativos Web 2.0 se moveram para longe de uma arquitetura orientada a serviços (SOA) com web baseada em SOAP serviços para coleções mais coesas de recursos da Web RESTful ". Esse é um exemplo de uso para quando seu serviço deve ser consumido em uma página da web. Isso também pode ser feito facilmente com o WCF, usando o WebHttpBinding. Não diz "Use o WebAPI para isso" .

Se essa questão se estender além do "como gerenciar a discussão" : eu usaria o WCF se os serviços fossem consumidos por clientes que não são da web, porque seus metadados permitem incrivelmente fácil acesso geração de clientes com o mesmo formato.

Gerenciamento de equipe à parte, você não escolhe um sobre o outro. Você precisa observar o objetivo de cada serviço da Web e usar a tecnologia apropriada para a parte específica do aplicativo. É como proibir procedimentos de loja quando a equipe está usando uma estrutura de entidade.

Our usage would be mostly for web, and we would expose our services over HTTP. In some cases (say 5 to 10 percent) we might need distributed transactions though.

Então você escreve esses 5 ~ 10% de serviços web no WCF. Se o serviço deve ser referenciado internamente em outros projetos, não há debate. A vantagem da capacidade de importar o contrato do 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 tipos a um novo nível.

Você escreve o que deve ser usado para solicitações públicas de api (talvez) / Ajax na API da Web do Asp.net.

Se é apenas uma chamada ajax específica da página, você pode usar o Asp.Net MVC.

Não escolha, aceite todos eles. As APIs do WCF e Asp.net servem para diferentes finalidades. Ninguém diz que você não pode ter maçã e laranja em sua salada de frutas. Tentando escolher um sobre o outro e empurrando-o para baixo cada cenário é apenas pura preguiça.

Nossa equipe teve uma discussão semelhante há alguns meses. O fator decisivo para nós foi como criar e implementar cada tecnologia. Como já estávamos criando um aplicativo MVC e estávamos usando o Knockout.js para vinculação de dados, estávamos efetivamente usando o 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-os nossos comandos para o padrão do MVVM. Nossa lógica de negócios para o aplicativo da web é envolvida 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, como também para qualquer outro site ou serviço que tenha consumido os dados expostos.

Embora isso possa não ser uma resposta popular ou hiper técnica, determinar o que você precisa primeiro e como ou se a tecnologia ajudará é o que ajudou minha equipe a decidir qual tecnologia usar onde.

In other words, we'd better use Web API, if we want to expose a service over HTTP, but use WCF when it comes to TCP and Duplex.

Essa seria a abordagem mais razoável. É muito comum ter os serviços WCF e WebApi no mesmo aplicativo da Web, onde ambos servem a propósitos diferentes.

Apenas para corrigir alguns argumentos:

WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes

Em muitos casos, os modelos WCF funcionam com sem atributos datacontract / datamember.

SOAP is not as readable and handy as JSON

Não é verdade, mas os serviços da Web do WCF geralmente carregam XML simples em vez de SOAP inchado. Isso definitivamente é legível.

Um argumento para WCF: se houver um WSDL disponível, há toneladas de 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 percorrer a linha com o WCF Data Services? consultas de estilo OData / webapi agradáveis e usabilidade com os poderes do WCF, e a capacidade de retornar JSON muito bem. Também Wcf não é tão ruim se você tiver um bom código de hospedagem wcf automático como o seguinte:

link

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 cadeia de correspondência operadores odata.

Um bom arquiteto atrasa as decisões de tecnologia até que seja absolutamente necessário fazer isso.

Em outras palavras, não tome a decisão até que um cliente precise realmente se conectar. Você pode criar uma camada de serviço totalmente testada sem realmente colocar um mecanismo de transporte / comunicação sobre ela. 95% + do trabalho pode ser feito "abaixo" do adaptador, fora do framework.

Hora de expor esses serviços a clientes remotos, você pode escolher a estrutura mais moderna e escrever invólucros finos em uma camada de serviço versátil.

Inferno, se a sua camada de serviço "real" for bem feita, você pode até experimentar vários wrappers com um gasto mínimo.

Essa é a resposta dogmática, de qualquer forma. Na prática , você pode escolher a ferramenta mais simples para facilitar o início e a frequência testes de integração - mas, ainda limitam a sua dependência e tratam-na estritamente como uma camada de comunicação simplesmente fina sobre os serviços real .

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 mais sofisticada ou moderna ou framework mais tarde, se necessário , com esforço mínimo.

Se eu estivesse em sua posição, começaria examinando as habilidades de sua equipe. Se todos da sua equipe já conhecem o WCF e apenas uma pequena porcentagem conhece a API da Web, sua decisão já foi feita para você.

Por todos os meios, se você tiver tempo, invista-o para aprender e melhorar sua base de conhecimento, mas não às custas da necessidade do negócio e da produtividade da empresa.

Gostaria de perguntar qual modelo de interação você precisa apoiar? Sua interface externa desejada se assemelha mais a RPC ou REST? Na minha experiência, geralmente está em algum lugar, mas principalmente um ou outro.

Você está consumindo seus próprios serviços para outros projetos no .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 ser capaz de construir e injetar seu cliente. Como uma extensão para isso, você pode montar seu projeto baseado em WCF com nós de extremidade JSON e SOAP / WSDL, eu fiz isso. O WCF também oferece melhores garantias contra suas 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 pontos de extremidade JSON simples possuem. Se você seguir a rota da API JSON / Web, precisará se tornar muito melhor em documentar como interagir com seus endpoints e com a API.

Em geral, sugiro escrever um documento de API simples que declare como você enviará dados e como deseja uma resposta para uma única estrutura de objeto de solicitação. Escreva seu caso de teste da maneira mais universal e documente-o como tal. Eu recomendaria uma declaração de onda simples. 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 quais vitórias.

Uma coisa além disso, é implementar seu cliente em dois idiomas diferentes. Faça um cliente em C #, mas também faça um em Node.js ou em Python e veja como eles realmente se encaixam. Esse exercício sozinho ajudará você a sacudir as pontas soltas da sua API.

Por isso estou enfrentando a mesma escolha agora, perguntei a mim mesmo qual é o subconjunto de recursos do WCF que nossa equipe está usando no momento. Nós usamos protocolos diferentes? Não. Usamos o suporte a transações? Não (embora usemos mecanismos de consistência eventual personalizados). Nós usamos duplex? Não.

Por que gostaríamos de usar a API da Web? Integração de frontend mais fácil (remove camada de serviço adicional existente agora), SignalR para empurrar resposta a clientes, armazenando em cache para GETs.

Pode ser, pode-se encontrar outras razões :) Também, razões para ficar com o WCF.