Spring y ibatis(myIbatis)

Hola:

he visto que la mayoria de los ejemplos hacen las funciones de los daos asi

@SuppressWarnings("unchecked")
public List findAll() throws ExcepcionDao {
try {
templateSpring=this.getSqlMapClientTemplate();
List listEmpleados = templateSpring.queryForList("getAllEmpleados",null);

return listEmpleados;
} catch (Exception e) {

logger.error(e.getMessage());
e.printStackTrace();
throw new ExcepcionDao(e.getMessage());

}
}

getEmpleados es una sentencia declarada en xml , duda es cuando se cierra la conexion spring lo hade solo mediante el spool de conexiones es asi?

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

pool

Es un pool, no spool... ese "templateSpring" que tienes supongo que es una clase de Spring que implementaron para trabajar con iBatis y que sigue el patrón de templates similar al que ofrecen para Hibernate, JDBC, etc, el cual te maneja el abrir la conexión y cerrarla al final, de modo que no tienes que preocuparte por cerrarla en caso que ocurra algo.

Se considera mala práctica interceptar Exception, realmente deberías solamente cachar los tipos de excepciones que realmente vas a manejar, y los que no, los declaras en el método si es necesario o simplemente los ignoras. Es menos grave si envuelves la excepción en tu excepción y la arrojas de nuevo, pero de todas maneras lo menciono.

"Se considera mala práctica

"Se considera mala práctica interceptar Exception", como deberia quedar el codigo de arriba , tengo que sacar el excepcion y ademas sacar ExcepcionDao
como quedaria entonces ??????

Imagen de ezamudio

encapsular

Lo único que estás haciendo es cachar cualquier excepción de cualquier tipo y encapsularla en un ExcepcionDao. Qué pasa si ocurre una NPE o alguna otra RuntimeException? Tengo que cachar ExcepcionDao y ver la causa, siempre. No digo que esté mal del todo, por eso al final te puse ue no es tan grave porque lo estás envolviendo en tu propia excepción, pero puede ser algo engorroso. Es un patrón que por ejemplo los stubs de Axis2 siguen; siempre arrojan RemoteException o AxisFault y tienes que abrirlo y ver la verdadera causa del error con ex.getCause().

En tu caso, lo único que creo que podría ocurrir en ese código tan corto es una NPE por mala configuración o alguna excepción de iBatis, que Spring ya envuelve en una RuntimeException de algun tipo específico (probablemente DataAccessException). En cuanto a la NPE pues déjala pasar, no vas a hacer nada al respecto de todas formas y quien use tu DAO tendrá que lidiar con ese problema; y la DataAccessExeption la puedes declarar en tu método, para que le sirva de guía a quien lo invoque (aunque siendo RuntimeException, tampoco tiene que cacharla si no la piensa manejar).

Gracias. Lo que pasa es que

Gracias. Lo que pasa es que estoy con spring e ibatis, y dicen que no debo ocupar el dao de ibatis ni la excepciones sino ligarlas a spring
entonces podria yo usar excepciones de sqlexcepcion que son las que mas interesan . o no??

a si el codigo es muy corto

a si el codigo es muy corto por eso me agrada mucho programar con ibatis con spring , ligandole las sentencias sql a ibatis , por cierto un grande

Imagen de ezamudio

Spring

Ya estás usando Spring. La clase SqlMapClientTemplate indica que el método queryForList en todas sus variantes, arroja DataAccessException. Esa excepción es de Spring, no de iBatis. Y es RuntimeException de modo que no tienes que cacharla en el DAO si no piensas manejarla.

Gracias Compadre, voy a

Gracias Compadre, voy a revisarlo, un saludo desde Chile