¿Cuántos EJB son demasiados?

Question

Actualmente estoy desarrollando una gran parte de la base de software en JavaEE. Hemos seguido las pautas generales de JavaEE que dice que cada conjunto relacionado de operaciones debe ir a su propio EJB. Actualmente tenemos más de 275 clases diferentes de EJB (beans de sesión sin estado). Es muy probable que este número crezca hasta duplicar ese número.

Me gustaría saber si los contenedores EJB están diseñados para contener tantos tipos diferentes de EJB. Me interesa saber si vamos a obtener una penalización por el mal rendimiento por tener demasiadas clases de este tipo, y si algunos ajustes del nivel del servidor de aplicaciones pueden ayudar a aliviar esos problemas hipotéticos.

Estamos usando Glassfish v2 con JavaEE 5 en Sun's Java 6, por lo que los consejos sobre esta plataforma en particular serían muy apreciados.

Answer 1

EJB deben ser de grano fino, por lo que no hay problema con lo que está haciendo si es coherente en su diseño.

Los EJB son solo clases, por lo que no hay nada de qué preocuparse, excepto la carga general, que es ortogonal a la cantidad de EJB que ha desplegado.

Si le preocupa el rendimiento, realice algunas mediciones de supervisión u otras medidas de rendimiento y vea cómo van las cosas a medida que agrega nuevas funciones.

Al final del día, ¿preferiría mantener menos clases con muchos métodos, o muchas clases con menos métodos? Sé cuál elegiría.

Answer 2

(¿Hay una manera que puedo decir "ninguna en absoluto" sin ser votada abajo?)

En un tono más serio, usar tantos como sea necesario. Mi regla de oro es (tanto para EJB como para las clases en general) si no puede describir completamente lo que hace la cosa en un nombre de clase de aproximadamente tres palabras, lo hace demasiado.

En lo que respecta al rendimiento, sospecho que si el sistema comienza a sufrir de "demasiados EJB" tendrá problemas mucho mayores en alguna parte.

Answer 3

EJB son componentes y no clases y debe pensar en ellos en ese término y expresar el diseño de su sistema de forma adecuada.

La granularidad del componente es obviamente dependiente del dominio.

Supongamos que estaba modelando una computadora (bastante pasada de moda) con EJB. Resistencias, transistores, bobinas, etc .: Estos son pojos. Chips y tableros son componentes. El montaje es el OÍDO.

La granularidad de la interfaz debe reflejar la función del componente.

Answer 4

EJB no es solo una instancia de clase normal. Necesita mantenimiento adicional en el contenedor, grupo de instancias, etc. Muchos EJB requieren mucho recurso en el servidor.

No creo que un sistema necesite cientos de EJB. Si bien también participé en una aplicación con 90 EJB, fue una pesadilla: < No hubo pruebas, y la implementación también es una tarea enorme.