Es String o es Int

Puedes usar   pero seguramente se te empezará a llenar tu código de if's así..

Podrías usar polimorfismo y dejar que el tipo de dato decida el camino.

Por cierto para el "instanceOf" tienes que usar un objeto, no funciona con primitivos.

Sería algo como:

Pero de nuevo debe de haber una mejor opción dependiendo de lo que intentes hacer.

pero qué cosa es un String o un int? o estás preguntando por  ?

No puedes preguntar directamente si algo es un   porque int es un tipo primitivo.

Mi codigo para criticas
 

Me parece que estás queriendo hacer tu propio ORM. A menos que seas uno de esos fanáticos anti-frameworks y anti-DRY, te recomiendo que mejor revises opciones como iBatis o Hibernate. Ambos están bastante maduros, bastante avanzados, y si tienes tu clase Recepcion o cualquier otra clase de dominio (o sea que la clase se mapea con una tabla o varias), puedes reducir todo ese código que tienes ahí a algo como esto:

Ahhhh el cláaaaaasico.

:) :)

Lee esto:

Y vuelvelo a leer hasta que te digas a ti mismo: Ok, voy a usar el prepared statement

Luego utiliza preparedStatement.setXyz( index, value );

O yaaaa en última instancia:

preparedStatement.setObject( index, value );

No construyas el string tu mismo.

En realidad no necesariamente escribir JDBC implica querer hacer un ORM, a veces dependiendo de la complejidad del problema se puede usar un TransactionScript ( es por ejemplo lo que usa StackOveflow dado el volumen )

Sin embargo lo que si está mal, es querer hacer lo que el driver de JDBC ya hace muy bien, que es crear el SQL correcto dandole formato a las fechas, numeros, strings y demás.

Ejemplo:

Y el driver hace lo correcto con cada uno.

como pasarias una lista en el pstmt?

¿Por ejemplo? Es decir: ¿como se ve el SQL a insertar?

Si te refieres así como un "select in " yo llegué a hacer algo como esto:

O algo así era, hace años que no hago eso, pero funcionaba muy bien.

Se puede argumentar que se va a crear un pstmt por cada combinacion, pero a favor diré en la aplicación habrá un número finito de combinaciones y habrá en el peor de los casos N pstmt, que pueden ser reutilizados por el RDBMS, por otro lado usar un statement simple involucra que el RDBMS va a "1.- parsearlo, 2.- Validarlo , 3.- Ejecutarlo" siempre. Y con el pstmt el día que se vuelva a dar la combinación .. se evita el paso 1.

Exacto a eso me referia. grax.

Aquí un ejemplo de por qué es importante usar PreparedStatements. La inyección de SQL es un peligro muy real.

Yo lo que entendí del código es que esta persona quiere hacer un generador de SQL para insertar cualquier objeto en su tabla correspondiente. Eso lo saqué del comentario del método guardar:

Eso me suena a que quiere hacer un ORM. Entiendo lo que dices y obviamente el primer paso sería simplemente arreglar su método para que use PreparedStatements, no concatene tanto, etc, pero eso no responde a la pregunta que puso en el comentario del método. Por eso me fui más allá y propuse una solución más a fondo, que es usar un ORM. Pero OK... nos podemos ir por una solución extremadamente rudimentaria y hacer nuestro propio ORM de petatiux, más o menos así:

Ahí les dejo de tarea agregar un mapa adicional con los tipos SQL para columnas que los requieran (java.sql.Types).

Leí un poco de hibernate y no cache mucho así que trate de hacer algo propio y que yo entendiera, gracias a sus comentarios estoy adquiriendo experiencias nuevas.

Muchas Gracias Saludos.

Los de las tablas en plural es por que también estoy usando cakephp para un par de cosas con esta misma BD y en las convecniones de este framework esta usar nombres en plural.

Yeap, es como si la historia se repitiera.

Alguna vez hice lo mismo pero entonces Hibernate ni existía lo que había era Toplink y la licencia constaba una lana.

Lo que yo encontré en ese entonces es que era mejor recibir el query que podía ser optimizado por un DBA y yo buscar al vuelo los objetos.

No era tan malo como parecía.

Lo usé un buen rato para iniciar mis desarrollos en lo que la gente de otros equipos hacía todo el código de BD y demás.

También me servia de sustituto de visor de SQL, jejeje tampoco había SQuirreL ni nada de eso y como lo que me importaba era ver la conexión JDBC pues no tenía caso usar TOAD o SQLNavigator ni nada de eso.

Le pongo un snippet en unos minutos de como se veía eso ( y como creo que se vería hoy en día )

Oscar (y cualquiera otra persona interesada), has visto Cayenne? Te recuerda algo?

Je je si.. demasiado parecido.

Alguna vez evalue los 4, Toplink, Cayenne, Hibernate y EOModeler, eso fue eeeen... el 2005 quizá :-S

En ese entonces me gustó más Cayenne, pero terminamos usando ( y después arrepintiendonos ) por TopLink

:)

Si no te quieres meter con un ORM como tal, revisa Apache DbUtils que te permite hacer algo similar, te ayuda con mucho de lo que quieres hacer, según recuerdo Spring tambien te da soporte para esto.

Como sea, revisa la documentación en el sitio de Apache, creo que no es algo tan difícil de comprender.

Después de una buena consulta a StackOverflow sobre como usar expresiones regulares, aquí va mi versión "actual" de algo que hice hace como 10 años y que quedo en el olvido.

En ese entonces, no había los muchos frameworks que hay ahora y yo recordaba el código mucho más extenso que este, pero con la experiencia y los cambios en Java esta versión ya no está tan horrible.

Un approach es como el que tiene Enrique hecho en 10 - 15 minutos, lo cual está super, pero conserva la desventaja del "mapeo" que en los ORM's es necesario; sino como XML, como annotations o en listas como lo muestra Enrique.

A mi nunca me gustó eso, pero es muy necesario de otra forma el ORM no puede general el query correcto.

Llendonos un paso más atrás, sin intentar Mapear un Objeto a una base de datos pseudo ( antes que nos caiga @Luxpes ) Relacional ( Por eso se llaman ORM's) , se puede hacer que le pasemos el objeto y el query que es exactamente como @Jvan dice con Apache DbUtils, Spring y creo que hasta Hibernate tiene soporte para algo así.

La idea es poder usar algo como esto:

Es decir pasarle el objeto y un SQL aribtrario e idealmente revisado por un DBA o que sé yo. Algo que pueda incluso copy/paste'tearse de la herramienta de SQL a Java, sin tener que romper muchas cosas. La "singularidad" está en usar una notacion :property para obtener el nombre del getter ( que por cierto, no estoy seguro sí así se usan parametros nombredos en SQL, pero algo así me arrojo Google )

El update quedaría así:

Es decir se construye un objeto   que después contiene los getters y el query sustituyendo los :property por "?" para ser usado por el prepared statement.

El chiste para no estar buscando los métodos una y otra vez está en tener un cache ( un mapa ) relacionando el query con este objeto, así solamente se ejecuta una vez:

Si ya está, lo usamos si no lo creamos:

Y listo!! ya podemos hacer algo no tan complejo como un ORM, pero sí mucho más eficiente que crear el query el vuelo.

Por ejemplo en un minibeanchmark, ejecutando este método 10 millones de veces se ejecuto en ~8 segundos ( vs. ~2 la versión sin reflection ) usando la opción "java -server", no sé si la JVM se da cuenta que no uso el valor y lo quita en la optimización, espero que no.

Solamente se crean "3" objetos   y claro, por cada uno solo hay una referencia a cada getter usado.

Salida:
 

Ahí les dejo el código por si alguien lo quiere probar en su base de datos, me dicen como les fue.

Se ve apantallador pero es extremadamente fácil ( cerca de 100 lineas sin comentarios ni bean de ejemplo )

El punto que quería ilustrar con mi ORM de petatiux, era que hay ciertos problemas que son complejos, punto. Un ORM es inherentemente complejo. Pero puede ser complejo por "debajo del cofre" y ofrecer una API inicialmente muy simple y que se vaya complicando conforme sea necesario... Esto por el comentario inicial de jamilMX cuando le sugerí Hibernate y dijo: "Leí un poco de hibernate y no cache mucho así que trate de hacer algo propio y que yo entendiera".

Así que en vez de leer algo de documentación, seguir un par de tutoriales, hacer unas pruebas, pelearse con la configuración inicial (siempre es una lata eso, con CUALQUIER framework; te peleas con la config al principio o después cuando quieres que se cambie algun parámetro que antes era automágico), en vez de trepar esa cumbre inicial para tener acceso finalmente a un framework bastante completo que resuelve tus problemas inmediatos y que está listo para resolver problemas que todavía ni tienes... no... mejor inventar el hilo negro y hacer tu propio ORM, qué tan difícil puede ser?.

Para tratar de ilustrar que no es simple, puse el código para insertar un objeto mapeado a una tabla. Cualquier Java Bean, mapeado a cualquier tabla, tal y como lo preguntaba en el comentario de su código:  .

Como yo lo veo, escribir código de ese tipo es un desperdicio de tiempo, porque ya hay cosas como Hibernate, Apache DbUtils, etc que ya lo hacen. Invertir tiempo en escribir ese tipo de código no es invertir tiempo, es desperdiciarlo, porque es tiempo que se puede usar en resolver los problemas de la aplicación que se está desarrollando, las cosas de la lógica de negocio, las pruebas necesarias, etc. Pero en vez de usar el tiempo en eso, se usa en escribir código de infraestructura, que no es simple, que no va a ser breve (mi método de inserción pinchurriento son 24 líneas, sin contar configuración y le faltan varias validaciones).

Saben lo que es la densidad de defectos? Es el número de defectos que se insertan por cada mil líneas de código tecleadas. Un buen programador puede tener una densidad de defectos de 60. Un programador promedio llega a 100. Eso significa que cada que tecleaste 10 líneas de código (efectivas, no contando una llave que cierra o una línea en blanco, etc), puedes estar seguro que tienes por ahí algún defecto: te falta un punto y coma, tienes una variable sin inicializar, o tienes algún defecto más grave, de esos que no salen en compilación, a veces ni en pruebas, sino hasta producción, porque solamente bajo ciertas circunstancias ocurre el problema.

Si mi densidad de defectos es de 50, entonces en esas 24 líneas de mi ejemplo de ORM de petatiux, es casi seguro que hay UN defecto. Y está super incompleto. Si vas a escribir tu propio ORM, y mide 500 líneas y tu densidad de defectos es de 60, entonces debe haber unos 30 defectos iniciales. Entonces, ¿para qué escribir ese código, cuando ya hay bibliotecas/frameworks que hacen lo mismo y mejor, porque ya fueron revisados una y otra vez y ya están mucho muy depurados?

Pero creo que se fueron por el lado de "ah pues yo lo haría de esta manera". No. La mejor manera es entrar a hibernate.org, ibatis.apache.org, y leer la documentación, hacer pruebas y elegir el que más convenga. ESO es invertir el tiempo, no estar escribiendo código de infraestructura tratando de reinventar el hilo negro.

No has propado con PreparedStatement y un HashMap...El PreparedStatement para que te ayude con lo de SQL-Injection y el HashMap pues que te diga el tipo de dato que es, por ejemplo:
 

De ahí, creo que puedes para "librarte un poco" utilizar un método de los preparedstatements llamado setObject. O en todo caso tener un super switch en donde incluyas los diferentes tipos y aplicar según sea el caso un setInt o setDouble o setString...

No necesariamente tiene que se un anti-frameworks o anti-DRY. Probablemente quiere hacerlo cómo un ejercicio, cómo lo estoy haciendo yo con el único fin de aprender bien lo que es la API de reflection.

Ahora, pues también está el otro lado que esté en una empresa donde pues no hay de otra y no eres quien decide que usar y por ejemplo un marco de trabajo de persistencia pues es algo a tomar en cuenta...Porqué de la mayoría de programadores un 80% te maneja bien SQL, pero sólo un 20% o 25% te maneja de manera aceptable un ORM for pros cómo los de Java que son muy flexibles PERO tienes que saber cómo usarlos (si, nada que ver con ActiveRecord u la implementación rara de Play! que se basa en hibernate sobre JPA) de lo contrario tendrás aplicaciones con persistencias lentas, por eso muchas empresas lo que hacen es usar algo "más estándar" y pasarse a consultas a más bajo nivel (que no de complejidad).

Tenía entendido que ahora ya no existe iBatis, ahora creo que el "sucesor natural" de iBatis es MyBatis...Aunque creo que si vamos a MyBatis es viajar al pasado del XMLHell. Francamente creo que si se quiere aprender un ORM no hay cómo aprender JPA, simple facilito y la configuración la haces en la misma clase sin tener que crear otro archivo de configuración (o propiedades).

Je je espero que no lo digas po mí.

Pero si así fuera, diré que lo que yo escribí me tomó 1 hr ( + / - ) ( más el tiempo de investigación de la regexp en SO ) y solo el 3/4 más de texto que te tomó a ti escribir la otra versión + el rant.

No es mucho y hay un fondo de todo esto. Ahora le vienen a llamar "Katas" pero es algo que siempre ha existido:

Practicar en resolver un problema que ya está resuelto te ayuda a mejorar tus habilidades de programador!

Es por todos aceptado que la mejor de mejorar es practicar. Para la mayoría de las disciplinas esta claro como practicar, si eres deportista entrenas hasta el desmayo, si eres músico practicas y practicas hasta que te vuelvas loco, si eres actor o bailarín te ves en el espejo ¿Y si eres programador? ¿lees blogs?, ¿libros?, claro que sí, te dan fundamentos que son muy necesarios ( de la misma manera que un futbolista tiene que estudar sistemas de juego ) ayuda claro , pero ¿cuando prácticas tu disciplina?, definitivamente no debería de ser con el código que va a producción. Es claro, no hay nada en el mundo como la experiencia con un sistema real, NADA ENSEÑA MÁS QUE EL SISTEMA DE PRODUCCIÓN ESTE ABAJO y tu tengas que levantarlo, pero hasta los polis entrenan ( o deberían ) y una muy buena forma de entrenar para ser programador ( si no es que la mejor ), es programando algo que sepas de antemano como se resuelve.

No es lo mismo leer el código y decir, "ahh si , ajá, ya le entendí", que luego tomar el editor, ver la hoja en blanco y decir Achís.. ¿como era? y luego poner los dedos en el teclado y ver como empieza a salir el código de tus dedos, sin tener que estar viendo el javadoc ( Já y pensar que hay quién no lo ve pero porque no sabe ni que existe ) ni tener que estar dependiendo del IDE siempre.

Ahora, no creas que no entiendo tu punto. Hay que ser responsable y usar las mejores herramientas para cada situación, cuando no se hace puede ser por ignorancia o por necedad.

La ignorancia es más o menos salvable, todos somos ignorantes por naturaleza y con el tiempo se quita e idealmente siempre hay alguien que evite que nos lancemos al vacío. Pero cuando se es necio si hay problemas, porque no hay forma de hacer entrar en razón a un necio.

Solo un necio o un ignorante pondría código como el que aquí publicamos directo en producción ( y peor aún, tal y como está ) habiendo tantas y tan buenas herramientas. No hay que hacerlo, hay que dedicar un buen tiempo en aprender bien las herramientas que están a la mano.

Hay que practicar mucho para poder usar esas herramientas bien y cuando se necesita.

En resumen, haganos caso a Enrique y a mí :) :) No re-inventen el hilo negro en producción y dediquen tiempo para practicar su programación.

Todo con exceso nada con medida

Una cosa que pongo en cuestión:

En resumen, haganos caso a Enrique y a mí :) :) No re-inventen el hilo negro en producción y dediquen tiempo para practicar su programación.

Yo sé que pues utilizar un framework sea a nivel qué sea, nos ayudan con experiencias previas de otras personas que se toparon con problemas, que si no son iguales a los nuestros son parecidos. Y qué mejor que utilizar la experiencia de otras personas y nosotros pues ni nos despeinamos en manejar el bajo nivel (por ejemplo para hacer un ORM propio tendríamos que saber utilizar la API de reflection y tener bases sobre metaprogramación). Sin embargo a veces es interesante hacerlo con el fin de obtener un conocimiento que no se tiene (en mi caso estoy haciendo un ORM con reflection).

Otra cosa es lo que ya dije en un comentario en esta entrada, muchas veces en las empresas se dice: "Vamos a hacer aplicaciones Java con JDBC y JSP."...Y tú puedes pasarte las horas dando millones de argumentos porqué sería mejor utilizar Spring MVC, Hibernate y otros módulos de Spring; pero muchas veces te dicen: "Sí, pero tú si sabes eso; el problema es que cuando tenga que contratar a alguien más necesitaré que sea alguien con un perfil muy específico; en cambio JDBC y JSP son cosas base de Java, por lo que la mayoría de programadores Java debe saberlas...es más simple para mí"...y cómo tu jefe es quien paga.

En mi conclusión, el reinventar el hilo negro tiene sus altos y bajos. Para mí sirve para aprender cómo es que las cosas funcionan; es cómo si te dijera: "¿Para qué haces otro lenguaje de programación, siendo que hay miles allá afuera que ya hacen lo que el tuyo?"...Quizás lo hiciste por una necesidad tuya, o por querer aprender cómo funciona un compilador, una máquina virtual, etc. Ahora, no hay que querer reinventar el hilo negro en nuestro trabajo diario; que ya tenemos suficientes problemas con los bugs del sistema cómo para acarrear los de nuestros propios e inmaduros frameworks ;)

creo que Oscar ya dejó muy bien establecido el punto de las katas de software, ejercicios personales de programación donde puedes programar algo que existe, precisamente para aprender cómo funciona. Posteriormente puedes ver el código de lo que estás intentando copiar (a menos que estés tratando de copiar algo propietario). Son, efectivamente, muy buenas maneras de practicas y es muy bueno que lo hagan para aprender.

Los comentarios que he hecho muy particularmente en este foro, son por lo siguiente: Si se fijan, la pregunta inicial ni siquiera era de un ORM, era una pregunta muy básica de Java cuya respuesta era simplemente la palabra reservada  . Pero luego salió a la luz la razón detrás de la pregunta y era hacer algo que se asemejaba a un ORM rústico. Y no tenía cara de ser algo para aprender a programar (al menos esa impresión me dio). Es confuso, tal vez inferí mal, porque pues la pregunta inicial es MUY básica y entonces podría ser un ejercicio escolar o alguien aceptó un proyecto que le está quedando grande o forma parte de un equipo de desarrollo donde ya tiene o quiere dar el paso a un nivel más avanzado pero en vez de irse por las piedritas se está queriendo aventar un gran brinco. Pero bueno, a mi simplemente me dio la impresión de que el programador que hizo la pregunta inicial y que posteriormente puso el código del INSERT que quiere hacer genérico, no lo está haciendo para aprender, sino por un encargo (de lo que sea). Si es código que va a llegar a un sistema en producción, sostengo todo lo que ya dije: no reinventar el hilo, utilizar frameworks de ser posible, etc. Si es un ejercicio de la escuela o personal para aprender a programar, adelante, ya pusimos algunos ejemplos aquí que pueden servir para aprender todavía más (ya después se me ocurrió que se puede usar una anotación como se hace con JPA, para decorar los getters indicando el nombre de la columna en base de datos y de paso el tipo SQL, y la clase se decora con una anotación que indique el nombre de la tabla).

En cuanto a los frameworks: entiendo que en muchos casos en empresas hay cierta oposición a adoptar algunos frameworks (o todos, cuando de plano sufren un grave caso de NIH). Como profesional del desarrollo de software uno puede presentar argumentos bastante válidos y ofrecer alternativas. No quieren usar Hibernate? OK, ni modo, pero eso no significa que la única otra opción es JDBC pelón; pueden usar JPA, es un estándar de JEE. O JDO, o pues ni modazo EJB 3.0... no quieren usar Play o Grails? OK pero eso no significa que usen JSP pelón; existe JSF que es otro de los estándares de JEE. Y así con varias cosas.

En cuanto a los frameworks: entiendo que en muchos casos en empresas hay cierta oposición a adoptar algunos frameworks (o todos, cuando de plano sufren un grave caso de NIH). Como profesional del desarrollo de software uno puede presentar argumentos bastante válidos y ofrecer alternativas. No quieren usar Hibernate? OK, ni modo, pero eso no significa que la única otra opción es JDBC pelón; pueden usar JPA, es un estándar de JEE. O JDO, o pues ni modazo EJB 3.0...

O tambien Spring-JDBC. Casi todos los casos en los que encuentro resistencia contra JPA o Hibernate, aceptan que se use Spring-JDBC.

no quieren usar Play o Grails? OK pero eso no significa que usen JSP pelón; existe JSF que es otro de los estándares de JEE. Y así con varias cosas

O Spring-MVC, puede que Play o Grails les parescan muy esotericos, pero Spring-MVC sigue siendo JSP (y puedes usarlo hasta con JDK 1.4 o mas antiguos)... o Weld, que tambien se integra (quiza hasta mejor) con JSP (aunque necesitas usar tomcat 6.0 y JDK 1.6 o superior).

Por otro lado, de usar JSP 2.0 pelon, a usar JSF 1.x, yo mejor me quedaba con JSP 2.0 pelon (disponible desde Tomcat 5.5), ya que JSP si tiene soporte para templating, y en cambio con JSF 1.x, si no te dejan usar tambien Facelets, entraras en un mundo de dolor interminable. En JSF 2.x, los Facelets ya estan integrados.

Hay algo que a veces manifestamos de manera involuntaria cuando queremos introducir una nueva tecnología en el equipo de trabajo y dominamos muy bien esa tecnología. Ese algo es que "hablamos de más" y espantamos al que nos oye. Vendemos por ejemplo Spring y comenzamos a contar todo lo que ese marco de trabajo ofrece. El que nos oye y no lo conoce se espanta de inmediato y su respuesta es: too much complicated".
Como bien comenta @luxspes, no es necesario ofrecer todo y es mejor empezar ofreciendo poco a poco lo que ese marco de trabajo ofrece. No creo que sea complicado para alguien que ya maneja un diseño con servlets y jsp ofrecerle Spring MVC como una alternativa. Si se vende bien, pienso que en la mayoría de los casos se acepta. Si muchos problemas de JDBC se resuelven con Spring JDBC, conviene comenzar por ahí y no tratar de convencer con ORM que inicialmente puede ser engorroso, y que en ocasiones no es necesario, aunque nunca diría que sale sobrando, porque lo que no es necesario hoy, quizá mañana lo sea.
Nuestra pasión por lo que sabemos a veces nos traiciona.

Hay algo que a veces manifestamos de manera involuntaria cuando queremos introducir una nueva tecnología en el equipo de trabajo y dominamos muy bien esa tecnología. Ese algo es que "hablamos de más" y espantamos al que nos oye. Vendemos por ejemplo Spring y comenzamos a contar todo lo que ese marco de trabajo ofrece. El que nos oye y no lo conoce se espanta de inmediato y su respuesta es: too much complicated".

Exacto, en ves de tratar de apantallar con todo lo que hace Spring-MVC, es mejor decir que "los controllers de Spring-MVC son como servlets, pero mas faciles de usar y de configurar" (ya me funciono una vez) y acontinuacion, mostrar un codigo implementado con servlets y otro con controllers, que deje ver los beneficios.

Lo mismo con los ORM vs JDBC. JPA e Hibernate ofrecen grandes beneficios, pero tambien un marco conceptual que, si no estas familiarizado con el, puede llevarte a rechazarlo. Spring-JDBC, en cambio, te permite seguir trabajando con tecnicas que hacen sentir comodos a programadores experimetnados en "JDBC Solito", y que les hace mucho mas comoda la vida. Es facil demostrar que Spring-JDBC permite hacer todo lo que JDBC un una fraccion de la complejidad, y sin tener que explicar cuestiones complejas.

(Diablos, mas posts en los que bferro y yo estamos de acuerdo... se ira a acabar el mundo? ;-) )

@luxspes cc: @bferro Siempre han estado de acuerdo solo que hasta ahora lo empiezan a notar.

@wishmaster77 Si usaras Ryz en producción el día de hoy, YO mismo te daba un cozcorrón ( dalee... unos ... 4 años más )

El código que he tirado aquí es para un proyecto laboral.
Un sistema de ABMC, pero en la marcha se me van ocurriendo cosas como lo del ORM, por ahora el proyecto no usara ningun ORM petatiux, se ira a como me esta marcando el libro de howto program 7a edición que es mi refrencia, aunque esta en ingles y es un poco mas complicado leerlo, pero se va adquiriendo soltura con el tiempo.
Tampoco soy un programador java con años de experiencia, solo llevo leyendo, testeando, probando, etc.. 6 semanas.
Donde inicie con conocimiento nulo de java, lo de instanceof si algo muy básico pero cuando no se tiene experiencia en un lenguaje uno quiere hacer las cosas como en lenguajes que conoces(Yo vengo usando php "cakephp" y python).
Y la verdad me ha gustado mucho java.

Saludos a todos y gracias por su colaboración.Me han servido como sensei y he cogido las mejores practicas de cada uno de sus comentarios :)

Gracias.

Jejeje...no era el punto, el punto es que tú hiciste Ryz con el fin de aprender algo no con el fin de reinventar algo ya hecho. Es por lo que defiendo el reinventar el hilo negro mientras no sea en producción ;)

Exacto, y finalmente absolutamente todos los inventos se generaron a partir de la idea de mejorar algo existente. El punto importante aquí es que para mejorar algo primero hay que conocer lo existente!

De lo contrario no hubiera existido ni Hibernate, ni Java, ni C++, ni C ni las computadoras ni nada y seguiríamos en la edad de las cavernas o trepados de algún árbol.

El ocio es la madre de todos los inventos!!!

Un poco tarde (mucho de hecho)

pues aqui tambien hay una forma de hacer esas comparaciones pero con el uso de reflexion

para los que no lo quieran/puedan leer:

Un sistema de ABMC, pero en la marcha se me van ocurriendo cosas como lo del ORM, por ahora el proyecto no usara ningun ORM petatiux,

de hecho... si tu pones ese codigo en tu sistema en production... estaras... poniendole a tu sistema un ORM de petatiux (con enfasis en el petatiux). Si es un sistema de produccion, ya construido sobre JDBC, yo te recomendaria invirtieras tiempo en introducir Spring-JDBC en el proyecto, con el fin de estandarizar y simplificar el codigo de acceso a datos...y mas adelante, para nuevos proyectos, pensar en utilzar JPA, sobretodo si esos nuevos proyectos son mas ABM que C.

Tampoco soy un programador java con años de experiencia, solo llevo leyendo, testeando, probando, etc.. 6 semanas.

De ahi que te convenga agarrarte de una base solida, como Spring-JDBC, y no hace experimentos tu solo. Por otro lado, por supuesto que es buena idea hacer experimentos de este tipo para aprender... pero... meter dicho codigo, que muy probablemente tendra una taza alta de defectos, en un sistema en produccion... bueno... eso no es para nada una buena idea...

Ahora, hacer un ORM es algo muy interesante, aunque sea de petatiux, yo he construido un par y se aprende mucho al hacerlo, pero no es un esfuerzo para nada trivial, y puede convertir un proyectito de 3 meses en un monstruo de 12 meses (de los cuales invertirás 11 haciendo el ORM). Es por eso que es mucho mejor idea usar algo como Spring-JDBC, si el codigo ya esta organizado para "uso directo" de JDBC, o de plano si es un proyecto nuevo, apoyarte en alguno de los ORM que siguen el estandar JPA (Hibernate, EclipseLink) o inclusive de los que lo siguen (como Cayenne, inspirado en EOF de NextStep).

Por otro lado, a los programadores nos encanta reinventar, y de la reinvencion han surgido grandes ideas... pero hay que tener cuidado de entender el precio que puedes acabar pagando por ellas...