Programación orientada a objetos

On Wed, 17 Jan 2007 18:10:09 +0100, "Alberto Poblacion"
wrote:

No necesariamente. Puedes tener los datos en base de datos y manipularlos
uno a uno en memoria según sea necesario. Por ejemplo, un objeto Cliente
tendrá un método Leer y otro Grabar, de forma que con Leer te lo traes desde
la base de datos a memoria, lo usas y modificas como sea necesario, y luego
llamas al método Grabar para devolver los datos a base de datos.

Esto es una práctica muy mala.

Tienes que decidir si deseas usar concurrencia optimista o pesimista. Es
más corriente usar la concurrencia optimista, que consiste en leer los datos
a memoria y no hacer nada en la base de datos (con lo que alguien podría
modificarla mientras tanto). En el momento de ir a grabar, se inicia una
transacción y se vuelve a leer el registro (lo cual lo bloquea en la base de
datos), se compara con el que leímos la primera vez (que habremos guardado
en memoria) y si no ha cambiado nada (que será lo más habitual), grabamos
nuestros cambios y terminamos la transacción. Si por el contrario
encontramos que algo ha cambiado, le mostramos un mensaje de error al
usuario del estilo de "lo sentimos, pero no se pueden grabar los datos
porque mientras tenías este registro en la pantalla, alguien lo ha
modificado desde otro terminal".
Si optas por usar concurrencia pesimista, añade un campo adicional en
los registros de la base de datos que sea "en uso". Cuando leas un registro
en un terminal pones a true ese campo en la base de datos, y si alguien lo
intenta leer desde otro puesto y se lo encuentra a true, le das un mensaje
de error diciendo que ese registro está en uso desde otro puesto. Cuando la
información se graba desde el puesto que la bloqueó, se pone false en el
campo "en uso". Hay que preveer un mecanismo de limpieza de ese campo por si
algún puesto se apaga mientras tiene un registro en uso.

Esto no tiene nada que ver con el control de concurrencia optimista y
pesimista

http://en.wikipedia.org/wiki/Optimi...cy_control
http://en.wikipedia.org/wiki/Concurrency_control


Saludos

On Wed, 17 Jan 2007 13:11:41 -0400, "Ana Zuluaga"
wrote:

Yo tambien he visto en ejemplos incluso de .NET en video de microsoft, que
usan un DataSet para un esquema desconectado, para ello trayendo muchos
datos innecesarios a memoria. Tambien pienso que muchos de los cursos que
se ven por ahi como que no son muy practicos para el clasico tema de manejo
de base de datos que debe tener en cuenta la constante concurrencia y sobre
todo mantener la integridad de los datos.

Es que de la concurrencia y sobre todo la integridad de los datos no
se tienen que ocupar las aplicaciones, es cosa del SGBD.

El "modelo desconectado" es un gran paso hacia atrás.


Saludos

On Wed, 17 Jan 2007 19:08:09 +0100, "Javito"
wrote:

Pero entonces para que unir las clases con asociaciones y establecer las
multiplicidades si nunca se van a traer dichos datos a memoria,

Para nada. No hay que hacerlo.

, en UML
pintas todas las clases del desarrollo y estableces las asociaciones con su
multiplicidad, y todo eso es solo teoria ? luego no se aplica ?.

UML no sirve para el tratamiento de bases de datos, eso se aplica a
otras cosas como por ejemplo el diseño de un procesador de textos o de
un compilador y cosas así.

Para trabajar con bases de datos hay cosas muchísimo mejores que el
OOAD y UML.


Saludos

On Wed, 17 Jan 2007 19:59:44 +0100, "Javito"
wrote:

Ya pero yo estoy haciendo un programa de reservas de plazas de hotel, que
ventaja me reporta que las reservas sean objetos de la clase reserva o que
obtenga lo que necesito directamente de la base de datos, de verdad que no
termino de ver la utilidad de la programación orientada a objetos, es un
capricho de alguien o que se gana con ello

Vamos a ver, la programación orientada a objetos tiene sus ventajas y
en algunos casos pueden ser importantes. En el caso de un programa de
reservas de plazas de hotel, la POO te va a aportar muy poco o nada.
Te puede ser útil si quieres crear nuevos controles visuales y poco
más.

Para crear sistemas de információn se utilizan otro tipo de técnicas.

Si en un curso de POO te ponen como ejemplo sistemas de bases de datos
es que no tienen ni idea de lo que te están hablando. Deberías de
abandonar el curso y pedir que te devuelvan el dinero.

En el famoso libro sobre patrones de la banda de los 4 no hay un solo
ejemplo sobre sistemas de bases de datos, y es una de las razones por
las que es un buen libro.

http://en.wikipedia.org/wiki/Design_Patterns

Es un libro bastante árido pero muy recomendable si quieres entender
mejor la POO.


Saludos

Javito schreef:

Ya pero yo estoy haciendo un programa de reservas de plazas de hotel, que
ventaja me reporta que las reservas sean objetos de la clase reserva

para gestionar datos... tienes razón! Lo que es una Reserva o un
Cliente
ya está, o debería estar, definido en la BBDD y no hacen falta clases
para eso.

o que
obtenga lo que necesito directamente de la base de datos, de verdad que no
termino de ver la utilidad de la programación orientada a objetos, es un
capricho de alguien o que se gana con ello

Hombre.. es que no todas las aplicaciones son del tipo de tus ejemplos.
La POO puede aportar mucho a la hora de modular aplicaciones my
complejas.
Puedes ver la OO como un forma de modular superior a la programacion
estructurada. Por ejemplo en los GUI (graphical user interface) la POO
a
sido un éxito, que es el ejemplo típico de lo bien que esta la OO.
Pero para gestionar datos... no.

De todas formas sigue siendo crítico y no te trages todo lo que lees.
Eso parece ser algo excepcional.

Saludos,
Carlos