¿Cómo gestiono el debate técnico sobre WCF vs. API web?

49

Ahora administro un equipo de unos 15 desarrolladores, y estamos atascados en un punto de elección de la tecnología, donde el equipo se divide en dos equipos completamente opuestos, debatiendo sobre el uso de WCF vs. API web.

El equipo A, que admite el uso de la API web, presenta estos motivos:

  1. Web API es solo la forma moderna de escribir servicios ( Wikipedia )
  2. WCF es una sobrecarga para HTTP. Es una solución para TCP, Net Pipes y otros protocolos.
  3. Los modelos WCF no son POCO, debido a [DataContract] y [DataMember] y esos atributos
  4. SOAP no es tan legible y práctico como JSON
  5. SOAP es una sobrecarga para la red en comparación con JSON (transporte a través de HTTP)
  6. Sin método de sobrecarga

El equipo B que admite el uso de WCF dice:

  1. WCF admite múltiples protocolos (a través de la configuración)
  2. WCF admite transacciones distribuidas
  3. Existen muchos buenos ejemplos e historias de éxito para WCF (mientras que la API web todavía es joven)
  4. Duplex es excelente para la comunicación bidireccional

Este debate continúa y no sé qué hacer ahora. Personalmente, creo que deberíamos usar una herramienta solo para su lugar de uso correcto . En otras palabras, será mejor que usemos API web, si queremos exponer un servicio a través de HTTP, pero usamos WCF cuando se trata de TCP y Duplex.

Al buscar en Internet, no podemos llegar a un resultado sólido. Existen muchas publicaciones para apoyar WCF, pero por el contrario también encontramos personas que se quejan de ello. Sé que la naturaleza de esta pregunta puede parecer discutible, pero necesitamos algunos buenos consejos para decidir. Estamos atrapados en un punto en el que elegir una tecnología por casualidad podría hacer que nos arrepientamos más tarde. Queremos elegir con los ojos abiertos.

Nuestro uso sería principalmente para la web, y expondríamos nuestros servicios a través de HTTP. Sin embargo, en algunos casos (digamos del 5 al 10 por ciento) podríamos necesitar transacciones distribuidas.

¿Qué debería hacer ahora? ¿Cómo manejo este debate de manera constructiva?

Saeed Neamati
fuente
11
No olvide que la API web no facilita que los consumidores generen un cliente de servicio como lo hace un SOAP WSDL. Si solo va a tener clientes .NET, no es un gran problema porque pueden compartir los objetos de contrato que implementa, pero otros clientes de lenguaje necesitarán crear manualmente sus objetos de cliente si no usa SOAP.
Jimmy Hoffa
10
También recuerda que WCF puede hacer json bastante decentemente en la mayoría de los casos también
Bill
3
"3. Los modelos WCF no son POCO", lo cual es simplemente incorrecto. No tiene que usar ningún atributo desde .NET 3.5 SP1.
Allon Guralnek
44
Esta pregunta parece estar fuera de tema porque se trata de gestionar un debate entre compañeros de trabajo, no sobre el desarrollo de software.
GrandmasterB
3
Wikipedia define "la forma moderna de escribir servicios"? No estoy seguro de cómo eso es útil.
Frank Hileman

Respuestas:

38

Cuando ambas partes tienen buenos argumentos y las opiniones sobre el tema son demasiado fuertes para llegar a un consenso, usted como gerente debe tomar una decisión y finalizar el debate. De lo contrario, se convertirá en círculos y fortalecerá aún más las posiciones de todos los participantes. Cuanto más espere, más difícil será para el lado "perdedor" admitir la derrota y trabajar productivamente con el resultado.

Escriba todos los argumentos, valore su importancia para el proyecto y luego tome su decisión. Cuando no puedas, lanza una moneda. Es probable que su proyecto se pueda completar con éxito con cualquiera de las tecnologías, y perder un tiempo valioso con debates innecesarios solo costará dinero innecesario.

Philipp
fuente
3
Estimado @Philipp, gracias por la sugerencia de lanzar la moneda . Pero como dije, no quiero arrepentirme de esta decisión casual . Si bien creo que la agilidad importa, también creo que las buenas decisiones también importan.
Saeed Neamati
55
@SaeedNeamati: Si, después de reunir y sopesar toda la información, ninguna tecnología tiene una ventaja clara, entonces lanzar una moneda es la forma más honesta de decidir. No importa el resultado del lanzamiento, es una buena decisión, ya que sopesó toda la información.
Bart van Ingen Schenau
99
@SaeedNeamati: Estoy completamente de acuerdo con "lanzar una moneda". En este momento se encuentra en una clara parálisis de análisis (sus palabras exactas están en esa página wiki), cuya OMI es más peligrosa que elegir una decisión que puede no ser "la mejor". Si tiene una decisión tan difícil, eso significa que incluso la otra decisión menos óptima no es tan mala. Y siempre que diseñe su software de forma modular, debería poder dejar suficiente abstracción para sacar una tecnología y poner la otra si es necesario, lo cual es muy poco probable en cualquier caso.
DXM
2
@SaeedNeamati En términos de tecnología, no hay tal cosa como "arrepentirse" de esta decisión. Siempre cometerás errores. Lo que es más importante es poder detectar errores lo antes posible, admitirlos abiertamente y cambiar la decisión para mejor.
Sleeper Smith
44
Otras opciones: lucha de nudillos; combate de lucha libre; La persona que grita más fuerte gana. ¿Seguramente estos son mejores que lanzar una moneda? :)
Frank Hileman
13

Asumiendo que ambas partes son 100% correctas en todos sus argumentos, ¿cuáles son importantes?

Los modelos WCF no son POCO, debido a [DataContract] y [DataMember] y esos atributos

¿Te importa? ¿Estás planeando hacer algo que requiera POCO?

WCF admite transacciones distribuidas

De nuevo, ¿es esto algo que vas a usar y necesitas construir si no lo tienes porque tomaste el otro camino?

Básicamente llegar al corazón de cuál:

  • Ofrece todo lo que necesita (si ninguno ofrece todo lo que necesita, lo que hace que tenga que hacer la menor cantidad de trabajo).
  • Ofrece la menor cantidad de basura que no va a usar, pero que tiene que soportar de todos modos.

Cualquier argumento presentado que no esté en el camino de lo que necesita lograr es irrelevante y no debe tener en cuenta su decisión, con cierto margen de maniobra para considerar la expansión futura.

metal de piedra
fuente
1
Los modelos de WCF Data Service son POCO, el único requisito es un iirc del campo ID [nombre].
Maslow
11

Pon mis dos centavos adentro.

Como gerente, debe pedirles a sus compañeros de equipo que tengan en cuenta el principio de Yagni . Esto ayudará a reducir la lista de razones presentadas por ambos equipos.

Nuestro uso sería principalmente para la web, y expondríamos nuestros servicios a través de HTTP. Sin embargo, en algunos casos (digamos del 5 al 10 por ciento) podríamos necesitar transacciones distribuidas.

En lugar de sumergirse en una transacción distribuida, debería considerar trabajar con una compensación .

Lo último a tener en cuenta es la curva de aprendizaje. Dependiendo de la fecha límite de su proyecto, como gerente, debería poder decidir si está bien comenzar a aprender una nueva tecnología o no.

Si tiene mucho tiempo que perder, entonces vaya a algún tipo de Día de la Innovación donde el Equipo A y B tengan un día para producir pruebas de conceptos basados ​​en los mismos requisitos.

Por cierto, para el tipo que dice "los modelos WCF no son POCO, debido a [DataContract] y [DataMember] y esos atributos ", dígale que los POCO generalmente están destinados a ser entidades de dominio y que no es una mejor práctica exponer su objeto de dominio para cualquier tipo de clientes, para eso están los DTO.

MaxSC
fuente
+1 por no exponer objetos de dominio en el fascade / contrato externo. Hizo esto al menos 10 veces por las ganancias baratas y en 9 de ellas refactorizadas debido al dolor de tener un contrato de comunicaciones fijo y gestionar un cambio de dominio. +1 para transacciones distribuidas, es una cosa muy malvada ..
user1496062
5

¿Qué debería hacer ahora? ¿Cómo manejo este debate de manera constructiva?

Primero, mantenga la subjetividad alejada. En los argumentos de su equipo de WebAPI, encuentro que "la API web es solo la forma moderna" *, "los modelos WCF no son POCO, debido a esos atributos" y "SOAP no es tan legible y práctico como JSON" bastante obstinado, si no es completamente incorrecto , y no ayudará a tomar una decisión.

Entonces, qué hacer: decida qué desea hacer con sus servicios , luego elija una técnica que se adapte a ese objetivo y su capacidad de mantenimiento y extensibilidad con la menor cantidad de dolor. Puede hacer esto simplemente investigando si algún aspecto es compatible con el marco a utilizar.

Material de lectura interesante:

*: tenga en cuenta que se refiere a Wikipedia para esto, donde la cita es: " Las aplicaciones web Web 2.0 se han alejado de una arquitectura orientada a servicios (SOA) con servicios web basados ​​en SOAP hacia colecciones más coherentes de recursos web RESTful" . Ese es un ejemplo de uso para cuando su servicio se va a consumir desde una página web. Esto también se puede hacer fácilmente con WCF, utilizando WebHttpBinding. No dice "Usar WebAPI para esto" .

Si esta pregunta se extiende más allá del "cómo gestionar la discusión" : usaría WCF si los servicios no van a ser utilizados por clientes que no son web, porque sus metadatos permiten una generación de clientes increíblemente fácil de escribir.

CodeCaster
fuente
1
No solo eso. " XYZ es la forma moderna " es un argumento nulo , que generalmente se lee como " No tengo argumentos reales, pero es mi favorito personal de la temporada " .
JensG
4

Dejando de lado la gestión del equipo, no elige uno sobre el otro. Debe analizar el propósito de cada servicio web y utilizar la tecnología adecuada para la parte específica de la aplicación. Es como prohibir los procedimientos de la tienda cuando el equipo usa el marco de la entidad.

Nuestro uso sería principalmente para la web, y expondríamos nuestros servicios a través de HTTP. Sin embargo, en algunos casos (digamos del 5 al 10 por ciento) podríamos necesitar transacciones distribuidas.

Luego escribes esos 5 ~ 10% de servicios web en WCF. Si el servicio debe ser referenciado internamente en otros proyectos, no hay debate. La ventaja de la capacidad de importar un contrato WCF para crear el proxy del cliente NO está abierta para discusión. Lleva toda la integración, eficiencia y seguridad de tipos a un nivel completamente nuevo.

Usted escribe lo que se utilizará para las solicitudes públicas de API (quizás) / Ajax en la API web de Asp.net.

Si solo se trata de una llamada ajax específica de la página, puede usar Asp.Net MVC.

No elijas, abrázalos a todos. La API web de WCF y Asp.net tiene diferentes propósitos. Nadie dice que no puedes tener manzana y naranja en tu ensalada de frutas. Tratar de elegir uno sobre el otro y empujarlo hacia abajo en cada escenario es pura pereza.

Sleeper Smith
fuente
4

Nuestro equipo tuvo una discusión similar hace un par de meses. El factor decisivo para nosotros fue cómo crearíamos e implementaríamos cada tecnología. Como ya estábamos creando una aplicación MVC y estábamos usando Knockout.js para el enlace de datos, estábamos usando MVVM de manera efectiva con los controladores simplemente como una API para datos.

Esto nos permitió clasificar nuestro uso de las tecnologías con este proyecto de la siguiente manera:

  • La API web se usaría como nuestra API para las llamadas de eliminación y Ajax, lo que las convierte en nuestros comandos para el patrón MVVM. Nuestra lógica de negocios para la aplicación web está envuelta detrás de esta capa a través de una serie de clases, repositorios y fábricas.
  • WCF luego se utiliza para nuestro almacén de datos, exponiendo datos de nuestra base de datos no solo para este sitio web, sino también para cualquier otro sitio o servicio que consumió los datos expuestos.

Si bien esto podría no ser una respuesta popular o hiper técnica, determinar qué necesita primero y cómo o si la tecnología ayudará es lo que ayudó a mi equipo a decidir qué tecnología usar y dónde.

Malla
fuente
¿Cómo maneja su capa WCF Auth?
Maslow
3

En otras palabras, sería mejor que usemos API web, si queremos exponer un servicio a través de HTTP, pero usamos WCF cuando se trata de TCP y Duplex.

Ese sería el enfoque más razonable. Es bastante común tener los servicios WCF y WebApi en la misma aplicación web donde ambos sirven para diferentes propósitos.

Solo para corregir algunos argumentos:

Los modelos WCF no son POCO, debido a [DataContract] y [DataMember] y esos atributos

En muchos casos, los modelos WCF funcionan sin atributos de contrato de datos / miembro de datos.

SOAP no es tan legible y práctico como JSON

No es cierto, pero los servicios web de WCF suelen llevar XML sin formato en lugar de SOAP hinchado. Esto definitivamente es legible.

Un argumento para WCF: si hay un WSDL disponible, hay toneladas de herramientas en casi todas las tecnologías que pueden crear proxies a partir de los metadatos. Por otro lado, el esquema JSON todavía no es ampliamente compatible.

Wiktor Zychla
fuente
2

¿Por qué no caminar la línea con WCF Data Services? agradables consultas de estilo OData / webapi y usabilidad con los poderes de WCF, y la capacidad de regresar JSONmuy bien. Además, Wcf no es tan malo si tienes un buen código de alojamiento de wcf automático como el siguiente:

https://github.com/ImaginaryDevelopment/MvcOdata

Diría que no están muy separados en absoluto, excepto que cuando los usamos WebApien el extremo frontal y WCF data servicesen el nivel medio, WebApiarrojamos cosas simples como cadenas de caracteres u operadores de odatos que coinciden con cadenas.

Maslow
fuente
1

Un buen arquitecto retrasa las decisiones tecnológicas hasta que sea absolutamente necesario tomarlas.

En otras palabras, no tome la decisión hasta que un cliente necesite realmente conectarse. Puede crear una capa de servicio completamente probada sin poner un mecanismo de transporte / comunicación sobre ella. El 95% + del trabajo se puede hacer "debajo" del adaptador, fuera del marco.

Cuando llegue el momento de exponer esos servicios a clientes remotos, puede elegir el marco más moderno del mercado y escribir envoltorios delgados sobre una capa de servicios versátil.

Demonios, si su capa de servicio "real" está bien hecha, incluso puede probar varios envoltorios a un costo mínimo.

Esa es la respuesta dogmática, de todos modos. En la práctica , es posible que desee elegir la herramienta más simple del estante para facilitar las pruebas de integración tempranas y frecuentes, pero, aún así, limite su dependencia de ella y trátela estrictamente como una simple capa de comunicación delgada sobre los servicios reales .


Si adopta este enfoque, probablemente encontrará que elige la herramienta más simple para usar inicialmente y nadie se preocupará , porque el equipo sabe que puede implementar una herramienta o marco más sofisticado o moderno más tarde, si es necesario , con un esfuerzo mínimo.

svidgen
fuente
Es cierto que esta respuesta es muy tarde para el juego - pero, yo estaba muy sorprendido de ver ninguna de las respuestas populares regurgitado la dogmática "ni siquiera tomar la decisión final todavía" respuesta ...
svidgen
0

Por lo tanto, me enfrento a la misma opción ahora, me pregunté cuál es el subconjunto de características de WCF que nuestro equipo está utilizando en este momento. ¿Utilizamos diferentes protocolos? No. ¿Utilizamos el soporte de transacciones? No (aunque usamos mecanismos de consistencia eventual personalizados). ¿Usamos duplex? No.

¿Por qué nos gustaría usar la API web? Integración frontal más fácil (elimina la capa de servicio adicional existente ahora), SignalR para enviar respuesta a los clientes, almacenamiento en caché de GET.

Puede ser, uno podría encontrar otras razones :) Además, razones para quedarse con WCF.

iiwaasnet
fuente
2
El OP no está preguntando sobre WCF vs Web API, el OP está preguntando sobre cómo administrar el debate técnico interno que está teniendo su equipo. Su respuesta pierde la parte más amplia de la pregunta.
0

Si estuviera en tu posición, comenzaría examinando las habilidades de tu equipo. Si todos en su equipo ya conocen WCF y solo un pequeño porcentaje conoce API web, entonces su decisión ya está tomada por usted.

Por supuesto, si tiene el tiempo, inviértalo en aprender y mejorar su base de conocimientos, pero no a expensas de la necesidad comercial y la productividad de la compañía.

usuario3333735
fuente
0

Me gustaría preguntar qué modelo de interacción necesita apoyar. ¿Su interfaz externa deseada se parece más a RPC o REST? En mi experiencia, generalmente está en algún punto intermedio, pero principalmente uno u otro.

¿Está consumiendo sus propios servicios para otros proyectos en .Net? Esta es probablemente la pregunta más reveladora que puede hacer. WCF tiene la ventaja de poder abstraer sus interfaces en una biblioteca de clases separada y poder construir e inyectar su cliente. Como una extensión de esto, puede montar su proyecto basado en WCF con puntos finales JSON y SOAP / WSDL, lo he hecho. WCF también ofrece mejores garantías contra sus interfaces definidas.

Dicho esto, si espera tener clientes de otras plataformas XML en general, mucho menos SOAP tiene una sobrecarga medible más allá de lo que tienen los puntos finales JSON simples. Si sigue la ruta JSON / Web API, deberá mejorar mucho más la documentación de cómo interactuar con sus puntos finales y API.

En general, sugeriría escribir un documento API simple que indique cómo enviará los datos y cómo desea una respuesta para una estructura de objeto de solicitud única. Escriba su caso de prueba de la manera más universal y documente como tal. Recomendaría una simple declaración curl. Luego, haga que varios de sus miembros implementen esto usando WCF y con API web. Entonces mira cuál gana.

Personalmente, a pesar de haber realizado algunos proyectos e implementaciones relativamente grandes con WCF, en realidad me inclino hacia la implementación más simple que, en mi opinión, es directamente WCF con el uso de resultados JSON y algunos comportamientos de anulación en Global.asax.cs para lidiar con condiciones de error. Si la documentación de una API incluye sentencias curl, y puede ejercer toda la funcionalidad de su API con ejemplos curl, será mucho más fácil implementar clientes en cualquier idioma que admita interfaces web. Aquí es realmente donde WCF comienza a caer. Tener una API bien definida con documentación agnóstica es mejor que tener estructuras con herramientas automatizadas cuando se trata de sistemas extranjeros. Hablando como consumidor de esos sistemas desde otras plataformas.

Una cosa más allá de eso es implementar su cliente en dos idiomas diferentes. Haga un cliente en C #, pero también haga uno en Node.js o Python y vea qué tan bien encajan. Ese ejercicio solo lo ayudará a sacudir los cabos sueltos en su API.

Rastreador1
fuente