capa de servicios WCF en aplicación de n-capas: consideraciones de rendimiento

Question

Cuando fui a la universidad, los maestros solía decir que en buena aplicación estructurada que tiene la capa de presentación, capa de negocio y la capa de datos. Esto es lo que escuché por más de 5 años.

Cuando empecé a trabajar he descubierto que esto es cierto, pero a veces es mejor tener más de sólo tres capas. Hace dos o tres días descubrí this article por John Papa que explica cómo usar Entity Framework en aplicaciones en capas. Según este artículo usted debe tener:

• capa de interfaz de usuario y la capa de presentación (Modelo Vista Patrón)
• capa de servicios (WCF)
• Capa de negocios
• de acceso a datos de capa

Servicio Layer es, para mí, una de las mejores ideas que he escuchado desde que trabajo. Su interfaz de usuario se "desconecta completamente" desde la capa de datos y negocios. Ahora, cuando profundicé en el código fuente provisto, comencé a tener algunas preguntas. ¿Puedes ayudarme a responderlas?

Pregunta n. ° 0: ¿es esta una buena plantilla de aplicación de enterpise en su opinión?

Pregunta # 1: ¿dónde debería alojar la capa de servicio? ¿Debería ser un servicio de Windows o qué más?

Pregunta # 2: en el código fuente proporcionado, la capa de servicio expone solo un punto final con WSHttpBinding. Este es el enlace más interoperable, pero (creo) el peor en términos de rendimiento (debido a la serialización y deserialización de objetos). ¿Estás de acuerdo?

Pregunta # 3: si está de acuerdo conmigo en la Pregunta 2, ¿qué tipo de enlace usaría?

Mirando hacia adelante a oír de usted. ¡Ten un buen fin de semana!

Marco

Answer 1

Pregunta # 0: es esta una buena plantilla de aplicación enterpise en su opinión?

Sí, para la mayoría de las aplicaciones de línea de negocio intermedias, es probable que sea un buen punto de partida.

Pregunta # 1: ¿dónde debo alojar la capa de servicio ? ¿Debería ser un servicio de Windows o qué más?

Si realmente quiere usar los servicios de WCF, entonces sí, recomendaría autohospedarlos en un servicio de Windows. ¿Por qué? No tiene que tener IIS en el servidor, no tiene que depender de IIS para alojar su servicio, puede elegir la dirección de servicio que desee y tiene control total sobre sus opciones.

Pregunta # 2: en el código fuente proporcionado la capa de servicios exponer simplemente un punto final con wsHttpBinding. Este es el enlace más interoperable pero (creo) el peor en términos de actuaciones (debido a la serialización y deserializaciones de objetos). ¿Está de acuerdo?

No, el más interoperable sería un basicHttpBinding sin seguridad. Cualquier pila SOAP podrá conectarse a eso. O bien, un webHttpBinding para un servicio RESTful, para esto, ni siquiera necesita SOAP, solo lo hará una pila HTTP.

¿Qué usamos?

• internamente, si Intranet-escenarios están en juego (servidor y clientes detrás de cortafuegos de la empresa): siempre netTcp - que es la mejor, más rápido, más versátil. No funciona bien a través de Internet, aunque :-((necesidad de abrir puertos en los firewalls - siempre una molestia)

• externamente: webHttpBinding o basicHttpBinding, sobre todo debido a su facilidad de integración con plataformas non-.NET

Answer 2

Aquí están mis 5 centavos:

0: sí

. 1: me gustaría empezar por lo aloja en IIS porque es muy fácil y te lleva a algún lugar rápidamente

2: Si necesita seguridad, definitivamente sí, vaya con WSHttpBinding (o tal vez incluso wsFederationHttpBinding si desea más seguridad de fance). Funciona bastante rápido en la práctica aunque, como dices, tiene algunos gastos generales, y puede ser bastante difícil llamar desde otras plataformas (como java).

3: N/A

Finalmente, recuerde para definir objetos de datos de contrato sus servicios en un conjunto separado que se puede hacer referencia tanto desde el DLL servicio y el consumidor en su capa de interfaz de usuario.

Answer 3

¿Sus profesores también le dijeron por qué debería crear una arquitectura así ;-)? Lo que me falta en su pregunta son sus requisitos. Antes de que cualquiera de nosotros pueda decirle si esta es una buena arquitectura o plantilla, debemos conocer los requisitos de la aplicación. Los requisitos no funcionales o las necesidades de una aplicación deberían impulsar el diseño de una arquitectura.

Me gustaría saber cuál es el requisito no funcional más importante de su aplicación? (Mantenibilidad, Portabilidad, Confiabilidad o ...). Por ejemplo, eche un vistazo a http://en.wikipedia.org/wiki/ISO/IEC_9126 o http://www.serc.nl/quint-book/

Creo que los arquitectos debemos crear arquitecturas basadas en los requisitos del negocio. Esto significa que los arquitectos deberíamos hacer que la empresa sea más consciente de la importancia de los requisitos no funcionales.

Pregunta # 0: ¿esta es una buena plantilla de aplicación de enterpise en su opinión?

Utiliza el patrón de arquitectura de capas, esto significa que las capas pueden evolucionar de forma independiente entre sí más fácilmente. Uno de los patrones de arquitectura más utilizados, tenga en cuenta que este patrón también tiene desventajas (rendimiento, trazabilidad).

Pregunta n. ° 1: ¿dónde debería alojar la capa de servicio? ¿Debería ser un servicio de Windows o qué más?

Difícil de responder. Alojar un servicio en IIS tiene dos ventajas, se escala más fácilmente y la trazabilidad es más fácil (WCF en IIS tiene muchas opciones de monitor). Hospedar un servicio en un servicio de Windows le brinda más opciones de enlace (enlace de canalización con nombre/enlace TCP).

Pregunta n. ° 2: en el código fuente provisto, la capa de servicio expone solo un punto final con WSHttpBinding. Este es el enlace más interoperable, pero (creo) el peor en términos de rendimiento (debido a la serialización y deserialización de objetos). ¿Estás de acuerdo?

En cuanto a rendimiento, el WSHttpBinding cuesta más, pero tiene un puntaje alto en interoperabilidad. Entonces la elección depende de sus requisitos no funcionales.

Pregunta # 3: si está de acuerdo conmigo en la Pregunta 2, ¿qué tipo de enlace usaría?

Las canalizaciones con nombre y la vinculación TCP son muy rápidas. Nombre El enlace de tubería solo debe usarse cuando se comunica en una sola máquina. El enlace TCP podría ser una opción, pero debe abrir un puerto especial en el firewall.