Programación orientada a objetos

Hola Ana,

On Thu, 18 Jan 2007 08:44:22 -0400, "Ana Zuluaga"
wrote:

Mostrar la cita

Viendo tus respuestas que me lucen interesantes, si es que no lo has hecho
ya, por que no nos colaboras escribiendo algo al respecto, no se, un
articulo y publicarlo para nosotros entender mejor. Si los tienes, dinos
donde podemos verlos.

Más que un artículo haría falta un libro entero, y ya los hay muy
buenos como este:

http://www.agapea.com/Introduccion-...11521i.htm

El problema es que a los buenos expertos en bases de datos les suele
interesar bastante poco la programación de aplicaciones. No conozco
ningún libro bueno escrito desde la perspectiva del programador de
aplicaciones, pero conciendo bien la teoría no es dificil sacar tus
propias conclusiones.

Mostrar la cita

En mi caso siempre me interesa aprender enfoques distintos que pueden
enriquecer nuestros conocimientos.

Eso está muy bien, y también es importante ser capaz de "desaprender"
enfoques y conceptos que han resultado estar equivocados.


Saludos
Alfredo

On Thu, 18 Jan 2007 06:50:03 -0800, Alhambra-Eidos
wrote:

Mostrar la cita

Mostrar la cita

Mientras no tengamos nada mejor no. Antes de confirmar la
actualización de un Dataset deberíamos enviar la petición de
actualización al SGBD y en caso de que la rechace debemos de abortar
la actualización del Dataset.

Y Microsoft ante esto qué determinación ha tomado ??

Creo que ninguna, pero es algo que se puede hacer sin muchos
problemas.

Mostrar la cita

Mostrar la cita

No, eso es mucho peor que los datasets.

He leído sobre otras posturas contrarias que apuestan por entidades de
negocio, y generación de código.

Si, yo también he leido muchas tonterías.

Mapear tablas con clases no añade ningún valor:

http://www.dbazine.com/ofinterest/o...es/pascal3

Y la generación de código no es una ventaja, es una engorrosa
consecuencia de un mal diseño:

http://c2.com/cgi/wiki?CodeGenerati...esignSmell


Saludos
Alfredo

Alhambra-Eidos schreef:
Mostrar la cita

Hola,


> > Qué utilizamos entonces, entidades de
> >lógica de negocio ??
>
> No, eso es mucho peor que los datasets.

He leído sobre otras posturas contrarias que apuestan por entidades de
negocio, y generación de código.

Esas son las posturas de los que no quieren entender que
reglas de negocio es un término informal que en realidad
describe lo que son constraints de integridad y que para
garantizar la integridad están las SGBD.
Son los mismos los que piensan que relaciones (tablas) y
tuplos son tipos (clases) y que un SGBD es solo un motor
de persistencia que no aporta mucho mas que una base
de datos XML (solo el término ya me da escalofríos).

Saludos,
Carlos

Carlos M. Calvelo schreef:
Mostrar la cita

Alhambra-Eidos schreef:
> Hola,

>
> > > Qué utilizamos entonces, entidades de
> > >lógica de negocio ??
> >
> > No, eso es mucho peor que los datasets.
>
> He leído sobre otras posturas contrarias que apuestan por entidades de
> negocio, y generación de código.
>

Esas son las posturas de los que no quieren entender que
reglas de negocio es un término informal que en realidad
describe lo que son constraints de integridad y que para
garantizar la integridad están las SGBD.
Son los mismos los que piensan que relaciones (tablas) y
tuplos son tipos (clases) y que un SGBD es solo un motor
de persistencia que no aporta mucho mas que una base
de datos XML (solo el término ya me da escalofríos).

Ya que estoy

Son los mismos los que no saben que un modelo jerárquico,
como xml o de clases en una estructura de herencia,
o que un modelo de red, como objetos interrelacionados
entre si en la memoria de un proceso por medio de
punteros, son modelos de gestión de datos deshechados
ya hace mucho tiempo.
Son los mismos los que no entienden que una base de
datos ocupa, a nivel lógico, un lugar central en un sistema
de información donde distintas aplicaciones pueden tener
vistas distintas de la organización de los datos
representados en una base de datos y que estas vistas
distintas tienen que integrarse para que las reglas no
se contradigan y para intentar que distintas aplicaciones
no tengan que saber nada de reglas que han impuesto
las demás.
Son los mismos los que parecen no querer entender
que una organización jerárquica no puede representar
distintas vistas de los datos, solo una.

Saludos,
Carlos

Mostrar la cita

Ana,
Sin ánimo de discordiar, esta no me parece una actitud sana.

Pues sin ánimo de discordiar, no entiendo que tiene de "insanidad" mi
simple planteamiento de arriba. Realmente insano me parece que traigas ese
adjetivo por los cabellos para referirte a lo que dije.


Mostrar la cita

La responsalidad de aprender es de cada uno y este no es
el sitio para aprender (casi) nada fundamental. >Como mucho
se puenden encontrar referencias.

Diciendo eso pienso que minimizas la capacidad/experiencia de los que aquí
participan. Si para ti no es el sitio adecuado para aprender, deberías irte
y no participar a menos que ya lo sepas todo. Para mí sí es un sitio donde
se pueden aprender cosas fundamentales ya que la gran mayoría de los posts
son expresiones de la experiencia, no de la teoría fría de los libros que en
muchísimos casos a las simples mortales como yo sólo hacen confundirnos
irremediablemente. Mi experiencia leyendo foros (hasta de forma pasiva) es
que han sido la principal vía de aprendizaje que he tenido por varios años y
estoy segura que de muchos colegas también.

Mostrar la cita

Evaluar estas referencias
es también resposalidad de cada uno. Algo no está bien o
mal porque alguien te lo diga.

Nadie ha establecido eso. Sólo que el que dice: "Eso no está bien" debe
completarlo diciendo qué es lo que considera que está bien. El contrastar
las posiciones sí ya es una responsabilidad de los lectores.