EJB3 Delegados Comerciales

Question

¿Hay alguna razón para hacer delegado al usar EJB3? Porque el único beneficio real que veo del delegado es que permite ocultar la búsqueda y acceder a los detalles de la arquitectura EJB. Bueno, también proporciona un poco de desacoplamiento, pero en su mayoría no se usa, en mi humilde opinión. Con EJB3 tenemos inyección, así que ahora solo puedo crear una variable con la anotación @EJB y usarla como está. ¿Todavía necesito delegados? ¿Está consumiendo este recurso de inyección? Me refiero a que si lo uso en la solicitud de JSF, ¿será mejor usar los delegados solo para disminuir las llamadas de inyección?

¡Gracias! recapitulación

Answer 1

Vamos a las fuerzas del original business delegate pattern:

• clientes la capa de presentación necesitan acceso a servicios de oficina.
• Diferentes clientes, como dispositivos, clientes web y clientes gruesos, necesitan acceso al servicio comercial.
• Las API de servicios empresariales pueden cambiar a medida que evolucionan los requisitos del negocio.
• Es deseable minimizar el acoplamiento entre los clientes de nivel de presentación y el servicio comercial, ocultando así los detalles de implementación subyacentes del servicio, como la búsqueda y el acceso.
• Es posible que los clientes necesiten implementar mecanismos de almacenamiento en caché para la información del servicio comercial.
• Es deseable reducir el tráfico de red entre el cliente y los servicios comerciales.

Todas estas fuerzas siguen siendo relevantes hoy en día - no son necesarios presente en cada proyecto, pero pudieron .

El principal cambio es que no necesitamos que el delegado comercial minimice el acoplamiento (el que está en cursiva). La inyección de dependencia resolvió el problema de búsqueda y acceso.

Me gusta el analysis from Adam Bien: uno de los puntos sobre el acoplamiento que todavía no se resuelve naturalmente es excepciones. Las excepciones ahora no están marcadas, pero aún existen. Si el cliente debe estar completamente protegido de las excepciones EJB o no, depende nuevamente de las fuerzas presentes en el proyecto.

En el caso de que se introdujera el patrón de delegado de negocios para resolver el problema de búsqueda y acceso (que sospecho que fue el caso para una gran cantidad de proyectos), efectivamente ya no lo necesitamos. Si el delegado comercial fue creado por otros motivos, aún puede tener sentido.

PS: desde mi propia experiencia, la inyección de recursos nunca fue un problema de rendimiento (siempre he tenido un problema más grave el rendimiento en otros lugares de la milésima de segundo que tarda la inyección :)

delegados

Answer 2

comerciales eran más que un truco para ocultar la kludge completo con búsquedas JNDI y toda la limpieza relacionada y captura de errores. La inyección de recursos entró en J2EE a través de Gavin Kings Seam, que básicamente sigue las pocas capas posibles y todas las configuraciones en un solo lugar. Así que olvídate de esos viejos patrones y solo usa OO normal.

Mis 2 centavos.

Answer 3

Bueno, en realidad no entiendo muy bien estos puntos.

Los clientes de nivel de presentación necesitan acceso a servicios empresariales.

Nivel de presentación en caso de que JSF se administre bean, ¿o no? Si es así, entonces este problema se resuelve mediante inyección. ¿Derecha?

diferentes clientes, tales como dispositivos, clientes Web y clientes pesados, necesitan acceso al Servicio.

No tengo dispositivos ni clientes gruesos. ¿Y qué es el cliente web? ¿No es el mismo nivel de presentación desde arriba? Si es así, entonces tenemos la misma situación que la anterior.

Servicios de oficina API pueden cambiar a medida que evolucionan los requerimientos del negocio.

No entiendo cómo los delegados pueden ayudar cuando la API cambia. Bueno, por supuesto, si solo se trata de pequeños cambios que puedes manejar simplemente cambiando el tipo de algunos parámetros pasados ​​o usando solo cierto campo en lugar de algún parámetro, entonces puede ser útil, pero no creo que tales situaciones ocurran a menudo, y no es tan difícil y puede ser incluso mejor cambiar la llamada al método desde el bean administrado o lo que sea. Mientras que los cambios importantes exigirán cambiar la llamada al método de todos modos.

Los clientes pueden necesitar para implementar el almacenamiento en caché mecanismos de Servicio al de información.

El almacenamiento en antememoria es una pregunta difícil ya que no sé qué caché y cómo hacerlo :) ¿Significa que puedo crear una variable que almacenará algunos resultados y usar llamada ejb solo cuando esta variable es llamado por primera vez? ¿Es una buena práctica para los recursos compartidos como debe ser un delegado?

Es deseable reducir el tráfico de red entre el cliente y el negocio servicios.

¿Cómo pueden los delegados reducir el tráfico de red? ¿Por la misma metodología con variable que almacena algunos valores?