Ayuda con metodo guardar generico

Ya hemos dado algunas respuestas a esa pregunta, en otro hilo.

Y que otro usuario tenga la misma duda en tan poco tiempo, me hace pensar que entonces es encargo escolar, no un proyecto real. Por lo tanto diría que mi respuesta es válida, aunque ahora podría aventarme la versión 2.0:

Primero que nada, se necesitan unas anotaciones. Una para la clase, y otra para los getters. Por el momento olvidémonos de la llave primaria, solamente manejemos el caso de que se puedan saltar algunas propiedades en el INSERT.

De modo que:

Y la de los getters:

Entonces para tener una clase que se pueda guardar, la decoramos así:

Y por último, el método para insertar es algo así:

Puedo asegurar que hay algunos bugs en este código, los cuales no me voy a tomar la molestia de buscar. Y falta cachar no sé cuántas excepciones de reflexión. Pero la idea es que ese método puede generar sentencias INSERT para instancias de clases decoradas con las anotaciones definidas para ello.

Y bueno, por decir algo, no sería igual de válido que en lugar de una anotación, extraiga las propiedades de los métodos getXXX() directamente, sin hacer la comparación de nombre de la columna??

@neko Si, pero eso solo serviría para el caso en que la columna y el atributo se llamen exactamente igual que... para este caso podría servir.

Por cierto en Abril uno de los ingenieros de StackOverflow ( o un equipo no sé ) sustituyó LINQ en el engine de SO por so propio ORM. En StackOverflow tienen muy fuertemente enraizado el síndrome de "no inventado aquí"

Ahi les dejo el link, aunque es de C# esta muy interesante:

Moraleja, solo haz tu propio ORM si sabes exactamente lo que estas haciendo.

La anotación te da ciertas ventajas sobre el uso puramente del nombre de los métodos:

1. Puedes tener getters que no quieres usar en el INSERT
2. Puedes ponerle el tipo SQL a la columna en la anotación
3. Puedes tener un nombre distinto en la propiedad Java y en la columna (esto es útil porque a veces tienes propiedades que en Java son válidas pero en alguna base de datos son palabras reservadas)

El punto 1 no lo ilustré pero si no lo usara, encontraría el método   por reflexión y no me interesa ese método.

El punto 2 lo ilustro poniéndole tipos a algunas columnas, y el punto 3 lo ilustro poniéndole nombre distinto a las propiedades dato1 y dato2.

Todo esto es solamente una prueba de concepto. Si ves JPA, la anotación   es bastante más completa, porque le puedes indicar el nombre de la columna en base de datos, el tipo, la longitud (por ejemplo para los VARCHAR indicar que no pase de 40 caracteres, etc).

O yaaaa deplano sin ninguna magia pero muy eficiente algo como esto:

Donde el sqlExecutor hace el manejo de los recursos y se encarga de obtener la conexión y liberarla.

Cada propuesta tiene sus limitantes. Las broncas en la práctica vienen cuando resulta que tienes un dato tipo Date que realmente quieres guardar en un campo de base de datos tipo TIME o tipo DATE (pura fecha, sin hora). Sin indicar el tipo de columna pues a ver qué sale... indicándolo ya puedes indicar si quieres TIME, DATE, o TIMESTAMP. Igual con cadenas, puedes indicar si quieres CHAR o VARCHAR o TEXT. Y lo mismo con los enteros (long, int, BigInteger, BigDecimal, float, double en Java) que van a TINYINT, INTEGER, NUMERIC, DECIMAL, BIGINT, etc.

En la propuesta de Oscar se puede hacer alguna inferencia de tipo según el objeto en Java, pero pues es agregarle un montón de if's, y de paso cambiar el   a   para que el método   haga algo que no sea insertar puros nulos...

Por cierto Groovy tiene este modulo llamado Groovy SQL ( bueno no sé si e le llama módulo, biblioteca o que ) pero puedes hacer cosas como las que dije usando una biblioteca que ya no es de juguete.

El intercambio va entre más flexibilidad/dinamismo menor desempeño.

Aquí algunos ejemplos tomados del articulo: Practically Groovy: JDBC programming with Groovy

O
 

Pues es una simple clase, pero bastante completa... de hecho en vez de usar los "?" puedes meter las variables ahí mismo como en cualquier GString y la sustitución de parámetros se hace posteriormente (no se va a crear la cadena vulnerable a inyecciones de SQL). Y puedes usar closures con varios métodos.

y de paso cambiar el pstmt.setNull a pstmt.setObject para que el método update haga algo que no sea insertar puros nulos...

Jajaj o para empezar declarar todas las variables para que al menos compile:

Ah va, ya entendí lo que dices, y sí, tienes razón, con las anotaciones de JPA puedes hacer un buen de cosas, incluso si todos los getters en tu bean no tienen nada que ver con las propiedades de alguna tabla que elijas ( bueno, suponiendo un caso extremo ) ... lo de Groovy ... bueno, ps ahí si no se que onda, no le he metido mano a Groovy, pero no se ve taaan complejo, así a primera vista, entendí lo que ilustran.... y la moraleja está bien pero...naaaaa, mejor invierto tiempo en configurar algo existente, que aventarme a hacerlo, a menos que me lo pidieran como tarea...