Capas estáticas en una aplicación web java.

Question

Estoy creando un pequeño sitio web para divertirme y aprender utilizando un diseño en capas de acceso web/servicio/datos bastante estándar.

Para evitar tener que crear constantemente instancias de mis clases de capa de servicio/capa de acceso a datos, he hecho que todos los métodos en ellas sean estáticos.No debería tener problemas de concurrencia ya que usan variables locales, etc. y no comparten ningún recurso (las cosas son bastante simples para esto en este momento).

Hasta donde puedo ver, la única desventaja de esto es que realmente no estoy siguiendo un verdadero enfoque OO, pero mantiene el código mucho más limpio.

¿Hay alguna razón por la que este no sería un enfoque viable?¿Qué tipo de problemas podrían surgir más adelante?¿Sería mejor tener una clase "de fábrica" ​​que pueda devolverme instancias de las clases de capa de datos y de servicio según sea necesario?

Answer 1

Desventajas:

• No podrá escribir pruebas unitarias, ya que no podrá escribir objetos simulados de lógica de negocios/acceso a datos para realizar pruebas.
• Tendrá problemas de concurrencia ya que diferentes subprocesos intentarán acceder al código estático al mismo tiempo, o si usa métodos estáticos sincronizados, terminará con subprocesos en cola para usar los métodos estáticos.
• No podrá utilizar variables de instancia, lo que se convertirá en una restricción a medida que el código se vuelva más complejo.
• Será más difícil reemplazar elementos de las capas comerciales o de acceso a datos si es necesario.
• Si tiene la intención de escribir su aplicación de esta manera, será mejor que utilice un lenguaje diseñado para funcionar de esta manera, como PHP.

Sería mejor optar por clases de capa de acceso a datos/negocios no estáticas mediante:

• Usando el patrón singleton (creando una única instancia de cada clase y compartiéndola entre hilos)...
• O crear instancias de las clases en cada hilo cuando sean necesarias.

Tenga en cuenta que cada usuario/sesión conectado a su aplicación se ejecutará en su propio hilo, por lo que su aplicación web es inherentemente multiproceso.

Answer 2

¿Conoce esas atracciones en el parque de diversiones donde dicen "por favor, mantenga las manos y los pies dentro de la atracción en todo momento"?Resulta que el viaje es mucho más divertido si no lo haces.La única desventaja real es que en realidad no estás siguiendo un verdadero enfoque de mantener las manos y los pies dentro del vehículo en todo momento.

El punto es este: hay una razón por la que debes seguir un "verdadero enfoque OO", así como hay una razón para mantener las manos y los pies dentro de la atracción: es muy divertido hasta que comienzas a sangrar por todas partes.

Answer 3

Tal como lo describe, este no es un enfoque "incorrecto" per se, pero realmente no veo el problema que está tratando de evitar.¿No puede simplemente crear una única instancia de estos objetos comerciales cuando se inicia el servidor y pasarlos a sus servlets según sea necesario?

Si está listo para tirar OO por la ventana, es posible que desee consultar también el patrón Singleton.

Answer 4

Realmente no veo la ventaja de su diseño y hay muchas cosas que podrían salir mal.¿Estás guardando una línea de código, tal vez?Aquí hay algunas desventajas de su enfoque:

• No puede reemplazar fácilmente las implementaciones de su lógica empresarial.
• No se pueden definir variables de instancia para facilitar la división de la lógica en múltiples métodos
• Es casi seguro que su suposición de que no surgirán problemas con subprocesos múltiples es errónea
• No puedes burlarte de ellos fácilmente para realizar pruebas.

Realmente no veo que la omisión de una línea de código te ayude a conseguir algo.

En realidad, no se trata de una cuestión de "diseño OO", sino más bien de idoneidad.¿Por qué estás usando Java de una manera tan procedimental?Seguramente PHP sería más apropiado para este tipo de diseño (y de hecho le ahorraría tiempo al no tener que compilar ni implementar).

Simplemente haría que su capa empresarial no fuera estática;Hará que sea mucho más fácil mantener, cambiar y evolucionar su aplicación.

Answer 5

Es posible que tenga dificultades para realizar pruebas unitarias de sus objetos con este tipo de arquitectura.Por ejemplo, si tiene una capa de objetos comerciales que hacen referencia a su capa de acceso a datos estáticos, podría resultar difícil probar la capa comercial porque no podrá utilizar fácilmente objetos simulados de acceso a datos.Es decir, cuando pruebe su capa empresarial, probablemente no desee utilizar los métodos "reales" en la capa de acceso a datos porque realizarán cambios no deseados en su base de datos.Si su capa de acceso a datos no fuera estática, podría proporcionar objetos de acceso a datos simulados a su capa empresarial con fines de prueba.

Answer 6

Creo que tendrá problemas de concurrencia con todos los métodos estáticos con múltiples usuarios.La capa web eliminará a los usuarios simultáneos.¿Pueden todos sus métodos estáticos manejar esto?Quizás, pero ¿no estarán constantemente encerrados en poner en cola las solicitudes en una sola fila?No estoy seguro, nunca probé tu idea.