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:
- Web API es solo la forma moderna de escribir servicios ( Wikipedia )
- WCF es una sobrecarga para HTTP. Es una solución para TCP, Net Pipes y otros protocolos.
- Los modelos WCF no son POCO, debido a [DataContract] y [DataMember] y esos atributos
- SOAP no es tan legible y práctico como JSON
- SOAP es una sobrecarga para la red en comparación con JSON (transporte a través de HTTP)
- Sin método de sobrecarga
El equipo B que admite el uso de WCF dice:
- WCF admite múltiples protocolos (a través de la configuración)
- WCF admite transacciones distribuidas
- Existen muchos buenos ejemplos e historias de éxito para WCF (mientras que la API web todavía es joven)
- 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?
Respuestas:
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.
fuente
Asumiendo que ambas partes son 100% correctas en todos sus argumentos, ¿cuáles son importantes?
¿Te importa? ¿Estás planeando hacer algo que requiera POCO?
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:
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.
fuente
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.
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.
fuente
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.
fuente
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.
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.
fuente
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:
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.
fuente
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:
En muchos casos, los modelos WCF funcionan sin atributos de contrato de datos / miembro de datos.
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.
fuente
¿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 yWCF data servicesen el nivel medio,WebApiarrojamos cosas simples como cadenas de caracteres u operadores de odatos que coinciden con cadenas.fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente