saludos y muchas gracias

atte.-Luis Guerrero

no sé si te he entendido bien, y no sé si me explicaré bien, estoy todavía enfermo y con los efectos de los antibióticos :S

hay varios tutoriales en la bitácora, dos de Struts1, uno de Struts2, este para integrarlo con Spring gracias al magnífico Chema… además llevo tiempo queriendo completarlos con otros tutoriales de iBATIS, Hibernate, Maven… pero no saco tiempo.

En este ejemplo concreto se utilizan una interfaz que puede ser implementada de varias formas. Por ejemplo, el acceso a base de datos, puedes construir diferentes implementaciones (una para bases de datos de MySQL, otra para SQL Server, otra para Oracle…). Luego cuando desplieges tu proyecto en un entorno concreto, utilizas una única implementación a dicho interfaz (por ejemplo, si en tu entorno de local utilizas MySQL y en preproducción y producción utilizas Oracle, en local implementarías el interfaz con la implementación de MySQL y en el resto con la de Oracle).

Para tu proyecto, simplemente elige el framework. Estos tutoriales son una base, y luego ya vas implementando el resto de tu proyecto.

Espero haberme explicado, si no es así dímelo

Te lo agradeceria mucho. Saludos.

Mi tiempo no es tan valioso, no más que el de cualquiera, simplemente cada día me apetece menos estar delante de un ordenador

Efectivamente, el error que me comentas se soluciona así, AppBaseAction debe de extender la clase Action de Struts, y nuestro controlador (LyckaRequestProcessor) debe extender del controlador de Struts (RequestProcessor)

Y si aprendes de tus errores, todo error nos acerca más a la verdad

Ya encontre la SOLUCION al ERRROR que te plantee anteriormente, se me prendio el bombillo luego que te escribi el post (me falto prestale un poco mas de atención al error), el problema era que la clase IdentificarAction la estaba extendiendo de AppBaseAction y esta a la vez extendia de LyckaRequestProcessor, lo que hice fue que la clase base en vez de extender de la clase LyckaRequestProcessor que extendiera de la clase Action de Struts y el problema desaparecio.

Si lo que hice es incorrecto te agradeceria mucho me corrigieras, porque tengo la duda con respecto a si la clase base debe de extender de la clase Action, por la cuestion que sobreescribimos el controlador de Struts.

Gracias y saludos….

Primero quiero agradecerte por responderme a las preguntas que te he hecho, y no te preocupes por el tiempo de demora, que entendemos que eres una persona con responsabilidades y ocupaciones como lo somos todos. Algo muy importante es que de tu valioso tiempo tomas un poco para ayudar a las demás personas, lo cual te lo agradecemos.

Ahora bien, se me ha presentado el siguiente error cuando intento correr la aplicación:

GRAVE: No action instance for path /identificar could be created
org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named ‘com.prueba.integrarstrutspringhibernate.action.IdentificarAction’ must be of type [org.apache.struts.action.Action], but was actually of type [com.prueba.integrarstrutspringhibernate.action.IdentificarAction]
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:322)

No he podido encontrar la solución a este problema, espero me puedas ayudar.

NOTA: Cambie para un nuevo correo para que si quieres me contactes por alli.

Gracias por tu ayuda….

Vale, ahora entiendo tu duda. En el ejemplo holamundoStruts138 tanto el negocio como la persistencia están implementadas con una única clase. En este ejemplo, cada una está implementada con un interfaz y una clase que lo implementa.

Cuál es mejor ? Yo con Struts 1.3.8 trabajé de la forma que puse en el ejemplo, una única clase. Sin embargo con Spring resulta fácil trabajar con interfaces y es lo recomendable desde el punto de vista de las buenas prácticas en el diseño. Así le puedes inyectar una implementación u otra en función de las necesidades.

Yo la verdad es que no lo veo tan útil salvo en casos concretos. La persistencia, cuando se piensa en que se puede cambiar de base de datos (cuántas veces ocurre esto). El negocio, para casos muy particulares. Por ejemplo, si tienes diferentes proveedores y les quieres aplicar distintos descuentos, puedes implementar un interfaz común a todo ellos e implementar una clase particular para cada proveedor que implemente sus respectivos descuentos o mecanismos particulares.

Respecto a lo de AppBaseAction, BaseBO y BaseDAO, tb es aplicacble a Struts 1.3.8, pero no lo puse por vago y para simplificar el ejemplo. Tiene que ver con otra buena práctica, la del desacoplo :
Framework > Arquitectura > Capa App > Clase
Los BaseBO y BaseDAO corresponden a Capa App, y contendrían las funcionalidades comunes a la capa y particulares para esa aplicación. No sé si me explico, esto da para otro post con más tranquilidad.

Vale, AppBaseAction no está suficientemente detallado en el post, a ver si saco tiempo para actualizarlo. AppBaseAction es lo mismo que BaseBO. Los actions de tu aplicación deberían de extender de AppBaseAction, y este debería de extender de la clase Action de tu Arquitectura (olvidémosla ahora), y esa de Arquitectura (o directamente este AppBaseAction) de la clase Action de Struts 1.3.8

Así estás aislando la aplicación para no tener que cambiar el código el día que se pase a Struts 2.0 : sólo habría que cambiar la Arq y AppBaseAction.

Fijate que la clase IdentificarBOImpl que colocaste en este post implementa IdentificarBO, pero ella es una clase (en el holamundoStruts138) no una interface, de alli que asumo que ese es unos de los cambios que hay que hacerle al menos a esta clase y a la IdentificarDAO.

Por otro lado, las clases BaseBOImpl y BaseDAOImpl son nuevas y me gustaria saber si deben tener una estructura especifica o si simplemente como tu digiste “todas las clases de negocio deberían de extender de una Base”.

Si entiendo bien la clase AppBaseAction, debe hacer lo siguiente (corrigeme si no es asi): La clase AppBaseAction debera extender de LyckaRequestProcessor y mis clases action ahora extenderan de AppBaseAction, y de alli continuo con los cambios.

Saludos.

no entiendo muy bien tu duda. Creo que te refieres a que ahora a las clases BO se les inyecta sus respectivos DAOs desde Spring. Por tanto se declaran los DAOs con sus respectivos Getters y Setters, y declaramos los beans

y luego los inyectamos al BO

Por otro lado, queria plantearte una duda que tengo, y es la siguiente, entiendo cual es la estructura de la clase IdentificarDAOImpl en base a la que tu has publica en este post (IdentificarBOImpl), pero no se cuales serian los cambios a nivel de las clases IdentificarBO, IdentificarDAO y cual es la estructura de las nuevas clases BaseBOImpl y BaseDAOImpl.

Te agradezco toda la ayuda que puedas prestarme,

Me seria de gran ayuda saber ademas la estructura de la clase AppBaseAction. Si no es molestia y si todavia tienen las fuentes a la mano, me podrian hacer llegar dichas fuentes…

De ante mano muchas gracias…