¿Cómo lidiar con monstruosas acciones de struts?

StackOverflow https://stackoverflow.com/questions/209516

Pregunta

Heredé esta gigantesca aplicación web Java heredada usando Struts 1.2.4. Tengo una pregunta específica con respecto a las acciones. La mayoría de las páginas tienen exactamente una Acción, y los métodos processExecute () son monstruos horribles (muy largos y toneladas de sentencias anidadas basadas en parámetros de solicitud).

Dado que las Acciones son una implementación del patrón de comando, estoy pensando en dividir estas Acciones en una Acción por gesto de usuario. Sin embargo, esta será una gran refactorización, y me pregunto:

  1. ¿Es esta la dirección correcta?
  2. ¿Puedo tomar un paso intermedio, un patrón que trate con el desorden dentro de las acciones monolíticas? Tal vez otro patrón de comando dentro de la acción?
¿Fue útil?

Solución

Mi forma de lidiar con esto sería:

  • no hagas 'todo a la vez'
  • cada vez que cambie algo, déjelo mejor de lo que lo encontró
    • reemplazar los condicionales con implementaciones de Acción separadas es un paso.
    • Mejor aún: haga que sus implementaciones se separen de las clases de Acción para que pueda usarlas cuando cambie los marcos
    • Mantenga su nueva implementación de Comando absolutamente sin referencias a Struts, use sus nuevas Acciones como Contenedor alrededor de estas implementaciones.
    • Es posible que deba proporcionar interfaces a sus Struts ActionForms para pasarlos sin copiar todos los datos. Por otro lado, es posible que desee pasar otros objetos que no sean ActionForms, que suelen ser un conjunto de cadenas (consulte su otra pregunta sobre Struts 1.2 ActionForms )
  • comience a migrar piezas a una versión más reciente y & amp; Mejor tecnología. Struts 1.2 fue genial cuando salió, pero definitivamente no es lo que quieres apoyar en la eternidad. Hay algunas generaciones de mejores marcos ahora.

Definitivamente hay más: lo siento, me estoy quedando sin tiempo aquí ...

Otros consejos

Las acciones Struts, en mi opinión, no deberían tener mucho código. Solo deben interactuar directamente con la solicitud y la respuesta: tomar algunos datos de un formulario o un parámetro de solicitud, entregar esa información a la capa de servicio y luego colocar algunas cosas en un objeto de Respuesta o tal vez guardar algunos datos en la sesión del usuario.

Recomiendo mantenerse alejado de hacer herencia con clases de acción. Al principio suena como una buena idea, pero creo que tarde o temprano te das cuenta de que estás haciendo más cosas de lo que estás haciendo que la base del código sea robusta. Struts tiene suficientes acciones básicas como están, si está creando nuevas probablemente tenga código en la capa web que no debería estar allí.

Esa es solo mi experiencia personal.

He tratado con este tipo de cosas antes. Un buen primer paso es insertar otra clase base en la cadena de herencia entre Acción y una de las clases de acción monstruosa original (llamémosla Clase A). Especialmente si no tienes tiempo para hacer todo a la vez. Luego, puede comenzar a extraer piezas de funcionalidad en clases de acción paralelas más pequeñas (ClassB, ClassC). Cualquier cosa que sea común entre la ClassA original y las nuevas clases refactorizadas puede ser incorporada a la nueva clase base. Así que la jerarquía ahora se ve así: 

Original Hierarchy:      New Hierarchy:

     Action                   Action
       |                        |
       |                      BaseA
  (old)ClassA                   |
                       +--------+----------+
                       |        |          |
                   ClassB (new)ClassA   ClassC
  1. Ir un método a la vez
  2. Grabe algunos casos de prueba que puede reproducir más tarde. Ejemplo aquí (asegúrese de presionar tantas rutas a través del código como pueda, es decir, todos los gestos de usuario en la página que llaman a esta acción)
  3. refactorice el método para reducir su complejidad creando métodos más pequeños que hagan cosas más pequeñas.
  4. Vuelva a ejecutar las pruebas mientras hace esto

En este punto, ha refactorizado la versión del gran método molesto. Ahora puedes comenzar a crear acciones específicas.

Puede usar su nueva clase refactorizada como clase base e implementar cada acción específica como una subclase usando esos pequeños métodos refactorizados.

Una vez que haya hecho esto, debe tener una buena imagen de la lógica compartida entre las clases y puede desplegar o eliminar esos métodos según sea necesario.

No es divertido, pero si trabajas en el código base por un tiempo, te ahorrará tiempo y dolores de cabeza.

Problema difícil pero típico del desarrollo temprano de aplicaciones web.

Lo primero es lo primero que debe comenzar a pensar qué lógica constituye un comportamiento empresarial, qué lógica constituye " flujo " (es decir, lo que ve el usuario), y qué lógica obtiene el contenido por lo que ve.

No tienes que seguir la ruta de las fábricas e interfaces y todo eso; la implementación retroactiva es mucho menos útil ... pero consolidar la lógica de negocios y la lógica de recuperación de datos en delegados de algún tipo ... y dejar las acciones de los puntales para determinar el flujo de la página en función del éxito / fracaso de esa lógica.

A partir de ahí, solo tienes que tomar algunas semanas y molerlo

Un método largo nunca es bueno, a menos que sea una sola declaración de cambio donde los casos son muy cortos (análisis de token o algo así).

Al menos podrías refactorizar el método largo en métodos más pequeños con nombres descriptivos.

Si es posible, puede comenzar su método reconociendo qué es lo que debería hacer al examinar el formulario, y luego, si es así, acceder a las diversas opciones. Sin embargo, no hay anidados, tienden a hacer que el código sea ilegible. Solo 

enum Operation {
  ADD, DELETE;
}

...

Operation operation = determineOperation(form);
if (operation == Operation.DELETE) { 
  doDelete(form); 
} else if (operation == Operation.ADD) {
  doAdd(form);
}

Si puedes llegar tan lejos, tienes una lógica agradable y limpia y puedes hacer cualquier refactorización que desees.

La parte difícil es aclarar tu lógica, y puedes hacerlo en pasos. No elija un patrón hasta que entienda exactamente cuál es su problema.

Si planea refactorizar el código, debe asegurarse de escribir primero las pruebas para el código existente, de modo que pueda asegurarse de que no haya modificado la funcionalidad una vez que comience a refactorizar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top