Como implementar mis clases con una base de datos

[Drknow]

Hola compañeros,como tengo tiempo libre estoy pensando en hacer un pequeño sistema de matricula que manejaria aprox 10 - 15 tablas o algo menos, algo simple.

La duda es que tengo problemas en como debo de implementar mis clases
es mejor hacer mi clase de conexion estatica e implementar todos mis consultas sp vistas y trigger o crear una clase especifica empleado,usuario,alumno,profesor cada una con sus respectivos insert select etc, algun modelo reutilizable basico que puedan implementar clases relacionadas con bd para tener una guia gracias.

[webness]

Pues haber, yo utilizo MVC, donde el las vistas son clases unica y exclusivamente con elementos java para crear vistas y/o mostrar datos, los eventos los invoco aqui pero los implementos en un paquete de eventos aparte, estos a su ves, llaman a los controladores donde hago todas las validaciones pertinentes. En el modelo lo parto en dos tipos de clases a) Estudent.java b) EstudentDB.java, donde en la primero represento un modelo de los campos de las tablas como tipos de datos de java, siendo las claves foraneas tipo de deatos de objetos, es decir si tu tabla "estudent" tiene una clave foranea id_ciudad, en Estudent.java, esto seria un Objeto de tipo Ciudad que representa la clase Ciudad., esta clase tiene los getters y los setters.. b) la clase EstudentDB.java posee los metodos de acceso a la base de datos, por ejemplo

pulbic Student[] getEstudentsByCourse(int course) ó

public void addStudentToCourse(int idEstudent, int int course) ó

public void modifyStudentPersonalData(Student student).

No soy muy amigo de los framworks, pero hibernate hace algo parecido.

Y las clases que terminan en DB, a la larga son el modelo.

[Drknow]

wow tengo que leer algo de hibernate MVC alguien mas puede opinar sobre como crear clases solidas, se que depende mucho de cada uno sobre los conceptos que llevas de la POO por eso necesito ejemplos pequeños con BD para crear algo solido y bueno, esto no solo me ayudaria ami si no tambien a muchos que se preguntan los mismos, se que se tiene que leer pero si no hay unos ejemplos no se puede entender nada bueno gracias.

[GreenEyed]

Depende del tipo de aplicación, los conocimientos que tengas, como se van a acceder a esos datos, la arquitectura del sistema... No hay una respuesta perfecta que valga para todo, al igual que tampoco hay una sola respuesta buena para cada problema.
Algunos ejemplos de cosas ha tener en cuenta
.- Los procedimientos almacenados permiten tenerlo todo en la BDD y el codigo fuente esta compilado contra el esquema de BDD, lo cual evita errores al modificar el esquema de la BDD. Sin embargo centraliza la carga en el servidor de BDD y es menos portable entre distintos tipos de BDD.

.- Un modelado orientado a objetos estilo ORM facilita la implementacion de la lógica y hacer uso de los estupendos IDEs de Java, además de ahorrarte escribir bastante SQL (aunque sigues escribiendo pseudo-SQL para cualquier cosa que no sea trivial). Además es más fácil de portar de una BDD a otra. Sin embargo, si el tratamiento de datos no se adapta bien al modelo clase=tabla, el rendimiento puede verse empeorado bastante y hace falta tener mecanismos para asegurarse de que la relacion ORM se mantiene correctamente cuando se cambia la BDD.

.- Un mecanismo de mantener las sentencias SQL de forma manual o semimanual es el más flexible y permite adaptarse a casi cualquier esquema de BDD y modo de proceso aprovechando al máximo el poder de SQL. Sin embargo requiere conocimientos de SQL y hay que escribir mucho código SQL parecido, además que el asegurarse de que el esquema de BDD y las sentencias SQL se mantienen sincronizadas corren a cuenta de uno mismo.

.- Si la BDD necesita poder ser accedida desde otras aplicaciones, hay que asegurarse que las caches intermedias (caso del modelo ORM) no interfieren y que se asegura la integridad referencial y las reglas de negocio se cumplen en todos los casos. Asi que si implementamos reglas de negocio en Java, por ejemplo, accediendo por SQL desde otra aplicacion habria que replicar esas reglas de negocio.

.- Segun lo que quieras hacer, un arquitectura Java 100% de arriba-abajo permite una mayor integracion y te suele da muchas facilidades, como poder usar tus objetos en la vista etc. Sin embargo te quedas atado facilmente a Java y a una tecnologia de vista dependiente, y en caso de cambiar la cosa se complica.

etc. . No es para asustar, es simplemente para dejar claro que hay muchas circunstancias y soluciones diferentes y que lo más importante es no quedarse obsesionado con encontrar LA solución, que no la hay.

Mi recomendación es encontrar algo que sirva para el problema que queremos solucionar y si algo nos da problemas, no quedarnos en eso por que es lo que alguien más usa o hemos leido. Al final lo habitual es acabar con un repertorio limitado de soluciones para los problemas que se suele encontrar uno, pero no hay que rasgarse las vestiduras por si nos encontramos un problema nuevo y lo que usabamos no acaba de servir. Hay que estar abierto de mente.

S!