Entender las aplicaciones orientadas a Objetos

"Javito" wrote in message
news:

1) En una aplicación orientada a objetos ¿ El Servidor carga todos los
objetos que necesita la aplicación cuando se inicia la misma ?

No tiene nada que ver. Lo de utilizar orientación a objetos se puede
hacer, por ejemplo, para programar un juego gráfico. No tiene por qué
existir un servidor ni cargarse ningún objeto en un servidor para que una
aplicación sea orientada a objetos.

2) ¿ Quiere esto decir que en estas aplicaciones no se accede a la Base de
Datos para realizar las operaciones, sino que se realizan sobre los
objetos en memoria ?

Eso es otra cosa. Estás pensando en un ORM (Object-Relational-Mapping),
que es un sistema en el que se "mapea" el contenido de la base de datos a
una serie de objetos en memoria. No todas las aplicaciones orientadas a
objetos tienen por qué usar necesariamente un ORM. Pero en caso de que se
use, no significa que no se acceda a la base de datos, sino que cuando se
accede, los datos de las tablas se almacenan dentro de objetos para
procesarlos más fácilmente en memoria. Lo normal es que, después de
manipular la información dentro de los objetos, se vuelva a grabar en la
base de datos.

3) Si hay varios usuarios trabajando en la aplicación y cada uno carga sus
propios objetos desde datos de la Base de datos, si tu has hecho algo en
un objeto en memoria, el que se incorpora a la aplicación al cargar los
datos desde Base de datos no va a tener tus cambios y habría
inconsistencia de datos ¿ como se evita esto ?

Cuando se trabaja así, se dice que se está usando el modelo de
"concurrencia optimista". Se asume que es muy improbable que dos usuarios
estén manipulando a la vez el mismo objeto, por lo que raramente existirá
una inconsistencia de este tipo. En los raros casos en los que se produce,
se detecta esta circunstancia porque en el momento de ir a grabar los datos
modificados se comparan los que hay en ese momento en la base de datos con
los que originalmente se leyeron. Si no coinciden, se asume que alguien los
ha modificado mientras tanto, y se resuelve manualmente la inconsistencia,
bien sea pidiendo la intervención del usuario, o bien mediante programación
en los casos en que se pueda.
Nótese que este problema se puede presentar con independencia de que se
esté usando un ORM. En un modelo tradicional en que se carguen los registros
del servidor en una simple estructura de datos en memoria, aun sin usar
orientación a objetos, existe el mismo problema de control de la
concurrencia.