¿Cómo administro el debate técnico sobre WCF vs. Web API?

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 terminar el debate. De lo contrario, solo girará 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 complete con éxito con cualquiera de las dos tecnologías, y perder un tiempo valioso en debates innecesarios solo costará dinero innecesario.

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

  

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

¿Te importa? ¿Está planeando hacer algo que requiere POCO?

  

WCF admite transacciones distribuidas

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

Básicamente, llega al corazón de cuál:

• Ofrece todo lo que necesita (si ninguno de los dos 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 vas a usar, pero tienes que aguantar de todos modos.

Cualquier argumento expuesto que no esté en el camino de lo que necesita lograr es irrelevante y no debería tomar en cuenta su decisión, con cierto margen de maniobra para considerar una futura expansión.

Poner mis dos centavos.

Como gerente, debes pedir a tus 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   sobre HTTP. En algunos casos (digamos del 5 al 10 por ciento) podríamos necesitar   Transacciones distribuidas sin embargo.

En lugar de sumergirse en transacciones distribuidas, debería considerar trabajar con compensación en su lugar.

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 tienes mucho tiempo para perder, entonces busca algún tipo de Día de la innovación donde los equipos A y B tendrían un día para presentar pruebas de conceptos basados en los mismos requisitos.

Por cierto, para el tipo que dice " los modelos WCF no son POCO, debido a [DataContract] & [DataMember] y esos atributos ", dígale que los POCO generalmente tienen la intención de ser las entidades de dominio y que no es una buena práctica exponer su objeto de dominio a ningún tipo de clientes, para eso están los DTO.

  

¿Qué debo hacer ahora? ¿Cómo gestiono este debate de manera constructiva?

Primero, mantén alejada la subjetividad. En los argumentos de su equipo de WebAPI, encuentro "La API web es simplemente la forma moderna" *, "Los modelos WCF no son POCO, debido a esos atributos" y " SOAP no es tan fácil de leer y útil como JSON ", si no está simplemente equivocado y no ayudará a tomar una decisión.

Entonces, qué hacer: decida qué quiere hacer con su (s) servicio (s) , 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 dado es compatible con el marco a utilizar.

Material de lectura interesante:

• Mvc 4 contra Wcf Web Api
• API web de WCF o ASP.NET? Mis dos centavos en el tema
• ¿WebAPI o WCF?

*: note que se refiere a Wikipedia para esto, donde la cita es: " Las aplicaciones web de la Web 2.0 se han alejado de una arquitectura orientada a servicios (SOA) con una web basada en SOAP Servicios hacia colecciones más cohesivas de recursos web RESTful ". Este 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, usando WebHttpBinding. No dice "Usar WebAPI para esto" .

Si esta pregunta se extiende más allá de "cómo gestionar la discusión" : utilizaría WCF si los servicios no sean utilizados por clientes que no sean web, ya que sus metadatos permiten una facilidad asombrosamente fácil generación de clientes de tipo.

Dejando a un lado la gestión del equipo, no eliges una sobre la otra. Debe ver el propósito de cada servicio web y usar la tecnología apropiada para la parte específica de la aplicación. Es como prohibir los procedimientos de la tienda cuando el equipo utiliza el marco de la entidad.

  

Nuestro uso sería principalmente para la web, y expondríamos nuestros servicios   sobre HTTP. En algunos casos (digamos del 5 al 10 por ciento) podríamos necesitar   Transacciones distribuidas sin embargo.

Luego escribe 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 posibilidad de importar un contrato de WCF para crear el proxy del cliente NO está abierta a discusión. Lleva toda la integración, la eficiencia y la seguridad de tipos a un nivel completamente nuevo.

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

Si es solo una llamada ajax específica de la página, puedes usar Asp.Net MVC.

No elijas, abrázalos a todos. WCF y Asp.net web api sirven para diferentes propósitos. Nadie dice que no puedes comer manzana y naranja tanto en tu ensalada de frutas. Tratar de elegir uno sobre el otro y derribarlo en todos los escenarios es pura pereza.

Nuestro equipo tuvo una discusión similar hace un par de meses. El factor decisivo para nosotros se redujo a 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, efectivamente estábamos usando MVVM, ya que los controladores solo eran una API para los datos.

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

• La API web se usaría como nuestra API para llamadas knockout y Ajax, convirtiéndolos en nuestros comandos para el patrón MVVM. Nuestra lógica de negocios para la aplicación web se encuentra detrás de esta capa a través de varias clases, repositorios y fábricas.
• WCF se utiliza para nuestro almacén de datos, exponiendo los datos de nuestra base de datos no solo para este sitio web, sino también para cualquier otro sitio o servicio que consuma los datos expuestos.

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

  

En otras palabras, sería mejor usar la API web, si queremos exponer un servicio a través de HTTP, pero usar WCF cuando se trata de TCP y Dúplex.

Ese sería el enfoque más razonable. Es bastante común que los servicios WCF y WebApi se encuentren en la misma aplicación web en la que ambos tienen diferentes propósitos.

Solo para corregir algunos argumentos:

  

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

En muchos casos, los modelos WCF funcionan sin atributos de datacontract / datamember

  

SOAP no es tan legible y práctico como JSON

No es cierto, pero los servicios web de WCF generalmente llevan XML simple en lugar de SOAP inflado. Esto definitivamente es legible.

Un argumento para WCF: si hay un WSDL disponible, hay un montón 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 totalmente compatible.

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

enlace

Yo diría que no están muy separados, excepto que cuando fuimos a usar WebApi en el extremo delantero y WCF data services en el nivel medio, WebApi arrojó cosas simples como la cadena contiene o encadena operadores de odata que coinciden.

Un buen arquitecto retrasa las decisiones tecnológicas hasta que son absolutamente necesarias para tomarlas.

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

Llegado el momento de exponer esos servicios a clientes remotos, puede seleccionar el marco más moderno y escribir sobre envolturas finas en una capa de servicio versátil.

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

De todos modos, esa es la respuesta dogmática. En la práctica , es posible que desee retirar de la estantería la herramienta más simple para facilitar el inicio y la frecuencia. pruebas de integración, pero aún así limita su dependencia y trátela estrictamente como una capa delgada de comunicación simplemente sobre los servicios reales .

Si adopta este enfoque, probablemente encontrará que elige la herramienta más sencilla de usar inicialmente y nadie se preocupará , porque el equipo sabe que puede implementar una herramienta más sofisticada o moderna o marco posterior, si es necesario , con un esfuerzo mínimo.

Si estuviera en tu posición, comenzaría por examinar las habilidades de tus equipos. Si todos los miembros de su equipo ya conocen WCF y solo un pequeño porcentaje conoce la API web, entonces su decisión ya está hecha para usted.

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

Me gustaría preguntar qué modelo de interacción necesitas apoyar. ¿Su interfaz externa deseada se parece más a RPC o REST? En mi experiencia, por lo general, se encuentra en un punto intermedio, pero en su mayoría uno u otro.

¿Está consumiendo sus propios servicios para otros proyectos en .Net? Esta es probablemente la pregunta más reveladora que puedes hacer. WCF tiene la ventaja de poder abstraer sus interfaces en una biblioteca de clases separada y ser capaz de construir e inyectar a su cliente. Como una extensión a esto, puede montar su proyecto basado en WCF con los 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, y mucho menos SOAP tiene una sobrecarga mensurable más allá de lo que tienen los puntos finales JSON simples. Si sigue la ruta JSON / Web API, deberá ser mucho mejor documentando cómo interactuar con sus puntos finales y API.

En general, sugeriría escribir un documento de 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 documéntelo como tal. Yo recomendaría una simple declaración de rizo. Luego haga que varios de sus miembros implementen esto utilizando WCF y con la API web. Luego ve cuál gana.

Personalmente, a pesar de haber realizado algunos proyectos e implementaciones relativamente grandes con WCF, en realidad me inclino por la implementación más simple que en mi opinión es WCF directa con el uso de resultados JSON y algún comportamiento de anulación en Global.asax.cs para tratar con condiciones de error. Si la documentación de una API incluye sentencias de curvatura y puede ejercer toda la funcionalidad de su API con ejemplos de curvatura, será mucho más fácil para los clientes implementarse en cualquier idioma que admita interfaces web. Esto es realmente donde WCF comienza a caer. Tener una API bien definida con documentación independiente es mejor que tener estructuras con herramientas automatizadas cuando se trata de sistemas externos. 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 te ayudará a sacudir los cabos sueltos de tu API.

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

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

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