java, bases de datos y objetos

Itubal
16 de Abril del 2006
Holas a todos:
Me gustaría hacer una aplicación de bases de datos en java un poco más grande que los ejemplos que suelen ponerse en los tutoriales. Vamos lo normal para una aplicación de estas. 12 o 14 tablas y un monton de consultas, listados etc...
Mi problema es que no sabria como organizar el código, que objetos deberia crear, si muchos o pocos y el tipo de los mismos y la comunicación entre ellos etc...
Alguien tendria unas palabras para mi? ¿y algun ejemplo? Muchisiamas gracias.

chuidiang
16 de Abril del 2006
Bueno, la verdad es que es un poco complicado y no hay solución única, cada uno tiene sus gustos.

Una posible solución es el empleo del patrón modelo-vista-controlador.

Como modelo debes hacer clases que representen tus datos. Deben tener mecanismos de suscripcion a cambios de los datos. Por ejemplo, y aunque sea un ejemplo de los tutoriales, si tus tablas son para un listín telefonico, puedes tener la clase Persona con sus datos , etc, etc, Las asociaciones entre ellas serían las normales para esos datos, una persona puede tener una clase Direccion, una clase Coche, etc. Una primera aproximación puede ser hacer una clase por tabla y manterner las asociaciones.

Luego están las clases de la vista. Son ventanas que reciblen clases del modelo para visualizarlas. Se suscriben a cambios en las clases del modelo para refrescarse. Pueden recibir listas de Personas, una Persona, etc.

Finalmente están las clases de controlador. Estas clases son las que tienen el conocimiento de todo. Cuando en una ventana se pulsa algo, se llama a un método de un controlador encargado de hacer las cosas. Este hara las consultas o inserciones en base de datos y actualizará las clases del modelo. Pasará clases del modelo a la clases de vista si es necesario.

Tienes un pequeño tutorial con ejemplo (aunque no hay base de datos implicada) en http://www.geocities.com/chuidiang/patrones/modelovista.html.

Se bueno

itubal
16 de Abril del 2006
Muchas gracias por tu respuesta.
En principio habia pensado hacerlo como comentas, pues es un modelo que he visto en entornos de programación. Pero necesito un poco más de detalle. Así que voy ahora mismo a ver el link que me pones. Si tengo alguna duda ya te preguntaré.
Y lo más importante... muchas gracias por tu ayuda.

zodiamoon
16 de Abril del 2006
hola, si además quieres un ejemplo cualquiera te puedo dar el mío, uso 64 tablas. Conste que puedo ser un ejemplo no muy bueno pero igual, por último por jugar y si sirve algo.

Es una aplicación con GUI (no web), tengo una aplicación cliente y un servidor, uso RMI (no sé si has revisado rmi pero es genial, o sea quizá para empezar, en j2ee hay cosas que debería tomar más en cuenta, pero depende de lo que quieras hacer. No siempre hay que matar una mosca con un cañón, o algo así).

Tengo efectivamente, casi tal cual, una clase para cada tabla, conocida tanto por el cliente como el servidor, por ejemplo Factura, DetalleDoc, Cliente, Mandante, etc. que tienen los datos y a veces algunos métodos que no se conectan a bd sino que algo hacen con los datos o calculan con ellos.

Además están las clases en el servidorque sirven al cliente, o sea otra vez FacturaV_, Cliente_, etc etc pero con los métodos que manipulan datos en la bd, por ejemplo, la clase FacturaV_ tiene un método así:
public void agregarNula(Usuario ID, int numero, java.sql.Date fechaEmision) throws RemoteException, MIException
{
try
{
Servidor.tomarConexion(ID);
Servidor.verificarPermiso (ID, 0);
PermisoSIONO.permisosSIONO = Usuario_.getPermisos_ (ID, ID.nick);
if (!PermisoSIONO.conPermiso (100))
{
if (!PermisoSIONO.conPermiso (101))
{ throw new MIException ("No tiene permiso para agregar facturas."); }
if (!UtilFechas.getS (UtilFechas.hoy()).equals (UtilFechas.getS(fechaEmision)))
{ throw new MIException ("No tiene permiso para agregar factura de fecha no actual."); }
}
if (Servidor.consultar
(ID, "SELECT * FROM FacturaV WHERE Numero="+numero).size()>0)
{
throw new MIException ("Ya existe una factura número "+numero);
}
FacturaV_.agregarNula_ (ID, numero, fechaEmision);
Servidor.liberarConexion(ID);
}
catch (Exception e)
{ Servidor.liberarConexion(ID); throw MIException.get (e); }
}

static void agregarNula_ (Usuario ID, int numero, java.sql.Date fechaEmision) throws SQLException
{
Servidor.ejecutar (ID, "INSERT INTO FacturaV (Numero, FechaEmision, "+
"FechaVencimiento, Anulada, IdVendedor, IdCentroCosto) VALUES ("+numero+",'"+
UtilFechas.getS (fechaEmision)+"','"+UtilFechas.getS (fechaEmision)+"', 1, null, null)");
}

En mi caso sólo creo la excepción MIException con el mensaje que quiera, no soy de los que crean muchos tipos de excep.

En el caso de arriba usé un método statico tb porque el agregar nula tb lo uso desde otro método rmi.

En el servidor tengo tb una clase para cada informe, por ej:

package facturacion.servidor;

import reutil.*;
import facturacion.cliente.*;
import facturacion.interfazrmi.*;
import java.sql.*;
import java.util.*;
import java.rmi.*;
import java.rmi.server.*;
/** Clase relacionada con el informe de listado de liquidaciones-facturas emitidas. */
public class InformeListadoLiqFacturasV_ extends UnicastRemoteObject implements InformeListadoLiqFacturasVI
{

public InformeListadoLiqFacturasV_(int puerto)throws RemoteException
{ super(puerto); }

public Informe get(Usuario ID, int idOrdenamiento, String idMandante, Periodo periodoE,
boolean soloConRet, boolean soloSinRet) throws RemoteException, MIException
{
try
{
Servidor.tomarConexion(ID);
...
Informe inf = new Informe ("LISTADO DE LIQUIDACIONES-FACTURA");
...
Servidor.liberarConexion(ID); return inf;
}
catch (Exception e)
{ Servidor.liberarConexion(ID); throw MIException.get(e); }
}

}

Igual es bueno que aunque seas una sola persona uses convenciones. La típica es de nombres de variables, pero por ej para manejar el estado de las ventanas (agregando/modificando/consultanto/ninguno) debería ser siempre igual.

zodiamoon
16 de Abril del 2006
hola, otras cosas, en mi aplic. sólo relaciono las clases que son espejo de bd por campos simples, por ejemplo el cliente tiene un .idComuna, no un objeto Comuna, sólo en contados casos incrusto el otro objeto. Pero tu gusto puede variar, cada quien se va acostumbrando a lo que va haciendo.

Pero algo importante es que hagas bien tu base de datos, relaciones las tablas y exijas integridad referencial. Además solicitar actualizar en cascada automáticamente, pero NO eliminar en cascada automáticamente. Me he topado con la sorpresa que algunas bd de algunos productos comerciales incluso son un asco. Donde hice la práctica la bd esa sí estaba buena, la hzo alguien bien inteligente, pero no le ponían actualizar en cascada entonces hacer algo como modificar un RUT era un pequeño lío.

chao y respóndanme la pregunta que puse en otro post, gracias.