🚀 go-pugleaf

leonardoazpurua@cantv.net escribió:
> On 8 abr, 12:55, Ricardo Palomares Martinez <rpm.PU...@iespana.es>
> wrote:
> 
> ¿Como agrego un archivo fuente preexistente a un proyecto en NetBeans?


Pues, si te digo la verdad, nunca he intentado editar un archivo
suelto desde NetBeans. NetBeans trabaja con proyectos completos; si
quieres añadir un conjunto de archivos que forman un proyecto (aunque
ese conjunto tenga un único archivo), tienes que crear un proyecto
nuevo: File -> New Project -> General -> Java Project with Existing
Sources o ... -> Java Project With Existing Ant Script.


>> Aparentemente, no hay discusión posible: si no usas un ORM, estás
>> muerto. En cambio, yo de momento no quiero usarlo. :-) ¿Por qué?
>> Porque, a mi juicio, el ORM oculta tanto de JDBC que siento que pierdo
>> el control de si los objetos con los que trato en el programa afectan
>> a los datos en la base de datos o no. Introduce, además, un montón de
>> conceptos nuevos, y como soy un poco novato, ya me sobran conceptos
>> que asimilar.
> 
> Al final, en el modelo de objetos, tiende a haber una relacion 1-1
> entre cada tabla de la BD con una clase del modelo.


Ojo, que yo me refiero a las instancias de las clases, no a las clases
en sí. Eso es lo que me asusta, no que una clase "Producto" tenga
correspondencia con una tabla DB "PRODUCTO", sino que tenga que llevar
cuidado en el código fuente para no recuperar un objeto "miProducto"
de la BD, cambiar algo en él y que ese cambio no se propague a la BD
sin que yo me dé cuenta. Con un objeto suelto es fácil controlarlo,
pero con muchos objetos de los cuales algunos los quiero propagar a la
BD y otros no me preocupa que ese control no sea sencillo.


> 
> Me preocupaba que la complejidad de usar directamente JDBC desde las
> aplicaciones fuera demasiada, pero al final es mas o menos la misma
> que la de ADO en el mundo de MS.


El mayor problema, aparentemente, viene de las divergencias entre los
distintos dialectos SQL de los fabricantes, y entiendo que eso también
pasará con ODBC, ADO y demás. Los ORM lo solucionan creando un
lenguaje de consultas "agnóstico" y lidiando ellos por debajo con cada
fabricante, pero para según qué cosas eso también lo hacen bibliotecas
más sencillas (p.e.: DdlUtils de Apache sirve para suministrarle un
XML con el esquema de una base de datos y que el propio programa cree
o ajuste la base de datos con la que realmente trabaja; para programas
pequeños que se van a pasar a muchos usuarios usando Java DB,
HSQLDB... todos ellos motores SQL pequeñitos basados en Java como si
fueran el motor de MS Access, usuarios a los que no quieres estar
dándole scripts SQL para que los ejecuten a mano, DDlUtils viene muy
bien).

De toda formas, a medio plazo los ORM pasarán a ser parte integrante
del lenguaje. De hecho, Java ya tenía algo para la versión empresarial
(Java EE) en forma de EJBs (Enterprise JavaBeans), y ahora lo ha
sustituido por JPA (Java Persistence Architecture), que se convierte
en la referencia para implementar frameworks ORM tanto en soluciones
SE (Standard Edition) como EE. Hibernate ya tiene, o está a punto de
tener, una versión que se ajusta a JPA.

Saludos.

-- 
If it's true that we are here to help others,
then what exactly are the OTHERS here for?