-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hola,
Estoy usando Struts desde hace alg�n tiempo, y me han surgido algunas dudas sobre la arquitectura mvc que usa. La situaci�n es la siguiente. Hemos desarrollado una aplicaci�n web/wap/sms usando Struts 1.1b2. Esto nos permite utilizar Tiles para generar las vistas jsp, lo que proporciona mucha mayor flexibilidad a la hora de presentar los distintos contenidos independientes en la p�gina, pero entremezcla de nuevo las tareas del desarrollador y del dise�ador (puesto que ninguna herramienta soporta Tiles, y no se prev� que lo hagan). Adem�s, en dicha versi�n, la gesti�n de las distintas vistas est� definida en distintas subaplicaciones. Es decir, existe un struts-config.xml para web, un struts-wap-config.xml para wap y un struts-sms-config.xml para sms, con lo que las peticiones desde wap y sms ser�n enrutadas a los subcontextos /wap y /sms respectivamente. Gracias a esto, el controlador, con una m�nima extensi�n (no en c�digo sino en configuraci�n), redirecciona a los "action" apropiados en funci�n del interfaz del cliente, los cuales a su vez tienen definida la vista en los citados ficheros xml. A priori, ser�a ideal que los "action" se mantuvieran para todas las vistas, y Struts simplemente enrutara y conectara las peticiones con los action y los action con las vistas en funci�n de las capacidades del cliente. Sin embargo, las limitaciones de unas tecnolog�as frente a otras en la capa de presentaci�n hace que el flujo de la aplicaci�n cambie: bien la paginaci�n, bien validaciones en cliente, etc. Por ese motivo, se tuvieron que definir clases Action particulares, para soportar estas alteraciones en el flujo. Como paso l�gico, en lugar de duplicar c�digo se extendieron las clases originales para introducir las peque�as variaciones necesarias. Lo primero que surge aqu� es el concepto de "herencia entre clases Action". Como en muchos otros casos, se utiliza la herencia sin que tenga mucho sentido en el dise�o, simplemente para no duplicar el c�digo. En realidad, las clases Action, te�ricamente, simplemente deber�an delegar la l�gica en el objeto de negocio correspondiente, pero aunque s�lo sea una linea la herencia evita la duplicidad de esa llamada. En el caso que expongo, adem�s de la llamada al objeto de negocio se realizan unas simples validaciones de los datos de entrada. Al final, la clase Action hija debe conocer las salidas de �xito o error de la clase que extiende para conocer qu� debe devolver ella, lo cual hace que el dise�o pida a gritos una revisi�n. Resumiendo, mis duda son: �C�mo se deber�an interpretar las relaciones entre entidades Action dentro del patr�n mvc? �Son los Action parte del controller? �C�mo se podr�a definir m�s expl�citamente el contrato (�xito/fracaso/error/etc) que debe satisfacer cada Action? �Se pueden considerar los "eventos" entre el modelo y la vista, gestionados a trav�s del controlador? Supongo que la herencia en el controlador tambi�n podr�a dar lugar a reflexiones similares. Gracias. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+OVrKIOG5AG0TzDURAiLoAJ0TdReMUTVU+ML/NFNMLcf01NRdBgCglitW sacDD7n4nvqxVVl97crvAi8= =hFO1 -----END PGP SIGNATURE----- --------------------------------------------------------------------- Para eliminar la suscripci�n, mail a: [EMAIL PROTECTED] Para comandos adicionales, mail a: [EMAIL PROTECTED]
