¿Porqué ADO.NET no soporta programación orientada a objetos?

On Fri, 9 Jun 2006 05:30:21 +0200, "Vyacheslav Popov"
wrote:

Eso si, usar apropiadamente un SGBD es incompatible con el OOAD, por
lo que hay que descartar el OOAD para cualquier sistema informático
que trabaje con bases de datos.

Si, claro, y dejar al usuario un manual de SQL y la consola de consultas.

Estás mezclando el tocino con la velocidad.

Las aplicaciones sirven precisamente para que los usuarios no tengan
que teclear instrucciones SQL en la consola.

Las aplicaciones son un sustituto amigable de la consola, y la lógica
de negocio debe de seguir siendo asegurada por el SGBD.

La teoría de bases de datos es mucho más sólida que la OO.

En algo estamos de acuerdo !(OO > BD)

Yo no estoy de acuerdo. Las dos cosas no se pueden comparar.

Es como decir (tocino < velocidad).

Pero cuando hay un conflicto entre lo que dice la OO y la teoría de
bases de datos hay que hacer caso a la teoría de bases de datos por
que tiene una base mucho más sólida.

Mira lo que opina el creador de la STL de la OO

I find OOP technically unsound. It attempts to decompose the world in
terms of interfaces that vary on a single type. To deal with the real
problems you need multisorted algebras - families of interfaces that
span multiple types. I find OOP philosophically unsound. It claims
that everything is an object. Even if it is true it is not very
interesting - saying that everything is an object is saying nothing at
all. I find OOP methodologically wrong.

http://www.stlport.org/resources/StepanovUSA.html

Te recomiendo leer la entrevista entera.


Saludos

On Fri, 9 Jun 2006 05:18:42 +0200, "Vyacheslav Popov"
wrote:

El modelo objetual no existe como tal.

Modelo relacional se representa con un Modelo E-R, a cambio, Modelo objetual
se representa con UML

Los modelos cada uno los representa como le da la gana. Los diagramas
de clases UML son casi iguales a los diagramas E-R, y ambos no son más
que dibujitos que proporcionan poca información y que son
completamente prescindibles.

La OO es un conjunto borroso de
técnicas de programación de bajo nivel sobre el que no hay acuerdo. El
Modelo Relacional es un sólido formalismo matemático dirigido a
gestionar bases de datos.

Para el Modelo Relaciona se utiliza álgebra relacional y para Modelo
Objetual se utilizan patrones de diseño.

Nunca es obligatorio usar patrones de diseño, y también existen
patrones de diseño para diseñar bases de datos relacionales. Pero es
cierto que no hay nada parecido al álgebra relacional en el mundo OO.
Por eso el Modelo Relacional es una forma mucho más potente de
gestionar datos. Fíjate en lo que dice Stepanov:

"I find OOP technically unsound. It attempts to decompose the world in
terms of interfaces that vary on a single type. To deal with the real
problems you need multisorted algebras - families of interfaces that
span multiple types."

El álgebra relacional es un ejemplo perfecto de este tipo de algebras
que se necesitan.

Las dos cosas no tienen nada que ver. No se

pueden comparar, son completamente independientes la una de la otra.

Por eso se aplica la técnica Object Relational Mapping (ORM)

Y también se aplican otras técnicas que dan muchísimo mejor resultado.

Clase: descripción de un conjunto de objetos que comparten los mismos
atributos, operaciiones, rlaciones y semántica.
Objeto: instancia de una clase.

A esto se le llama una definición circular. No sirve para nada. Además
de que es muy floja.

Has escrito que un objeto es un ejemplar de una descripción de un
conjunto de objetos. No hay por donde cogerlo. Lo de la semántica es
otra tontería que no se de donde la habrás copiado.

Objeto persistente: objeto qeu existe después de que el proceso o hilo que
lo creó deja de existir.

Si un objeto es un ejemplar de una clase (un valor) entonces no ocupa
lugar ni en el tiempo ni en el espacio, por lo tanto no se puede crear
ni destruir.

Lo que pasa es que "objeto" es la confusión de dos de los conceptos
clave de la programación imperativa: valor y variable. Aunque muchas
veces también se confunde con el concepto de tipo como cuando se dice
que un objeto tiene operaciones.

Los resultados de confundir dos cosas tan diferentes y tan importantes
nunca son buenos. Una parte muy importante de las tonterías que se
dicen sobre la OO vienen de no tener claros los conceptos clave de la
programación imperativa: tipo, valor, variable y operador.

Sistema de información: conjunto de funciones o componentes
interrelacionados que forman un todo, es decir, obtiene, procesa, almacena y
distribuye información para apoyar la toma de decisiones y el control en una
organización. Igualmente apoya la coordinación, análisis de problemas,
visualización de aspectos complejos entre otros.
Aplicaciones informáticas: son los programas con los cuales el usuario
final interactúa, es decir, son aquellos programas que permiten la
interacción entre el usuario y la computadora.

Esto no está mal del todo.

Un Sistema de Información está formado por un conjunto de aplicaciones
que interactuan. Dentro de un Sistema de Información bien diseñado hay
un subsistema que se ocupa de gestionar los datos garantizando toda la
lógica de negocio (SGBD). Por lo tanto las aplicaciones se deben de
encargar de la presentación y la comunicación con los usuarios. Las
aplicaciones son un puente entre los usuarios y el subsistema de
gestión de bases de datos. Las aplicaciones deben de transformar las
acciones de los usuarios en órdenes para el SGBD y presentar las
respuestas de forma cómoda.

Las aplicaciones forman el subsistema de presentación y comunicación
de un Sistema de Información.

SI = Subsistema de presentación + Subsistema de gestión de datos aplicaciones + SGBD.

Responsabilidades:

-Aplicaciones: comunicación con los usuarios
-SGBD: gestión de los datos incluyendo en mantenimiento de su
integridad y la derivación de nuevos datos.

En mis aplicaciones todos los "objetos" son transitorios, por que toda
la información importante se encuentra gestionada por el SGBD.

Creo que la "programación orientada a objetos" no te va a gustar.

La uso desde hace 16 años y tiene sus cosas buenas, pero no es ni
mucho menos la panacea y tiene una base teórica muy débil. Casi todo
lo que se escribe sobre POO son tonterías.

Abstracción es otra de las ventajas POO.

El nivel de abstracción de la POO es solo un poco mejor que el de la
programación clásica y muy inferior al del Modelo Relacional.

Lo que hacen esos mal llamados motores de persistencia es sacar el
máximo común denominador de los sistemas a los que se encapsula, es
decir te ofrecen la funcionalidad del peor de los sistemas. Tienes un
SGBD, pero tienes que acceder a los datos como si solo tuvieses un
archivo simple.

Si por ti fuera: SELECT titulo, descripcion, fecha FROM GOOGLE WHERE q LIKE
'%motores%persistencia%'

Si Google tuviese algo parecido sería desde luego muchísimo más
potente de lo que es.

Igual que WinFS es mucho más potente que los sistemas de archivos
jerárquicos.


Saludos

La de este hilo es como un tema para un articulo y tal vez muy avanzado para
nosotros simples mortales de este foro. ;-)


"Vyacheslav Popov" escribió en el
mensaje news:

C# es un lenguaje de programación moderno, completamente orientado a
objetos y el que más me gusta...
pero ¿porqué ADO.NET no soporta programación orientada a objetos?

No se a lo que llamás "quedar más limpio", pero lo que es seguro es

que hay que escribir muchísimo más código lo que implica que el
desarrollo y mantenimiento sean una pesadilla. Si mejoras el hardware
de algo que va rápido irá más rápido. Si lo mejoras en algo que va
lento irá menos lento.

R. Con limpio me refiero a que no tienes tanto codigo "plomeria". (Abrir la
conexion, crear el objeto Command, exejcutar la consultar,
Abrir el DataSet, etc). Esto quizas lo puedes minimizar con una buena clase
como los Application Blocks o usando algun patron de diseno pero
efectivamente no creo que sea el camino mas facil...
La mejora del Hardware mejora cualquier cosa pero si debo hacer un
mantenimiento prefiero algo donde tengo que invertirle menos tiempo..

Y así les luce el pelo. No son precisamente un ejemplo a seguir.

R. Si Hibernate no fuera un buen proyecto no fuese casi un estandard, no te
parece ? Ademas no tiene un marketing detras de ello
ya que es un proyecto gratis..

Si tu objetivo es maximizar el coste de desarrollo y mantenimiento y
crear código que solo tu eres capaz de entender entonces si que puede
valer la pena.

R. Si tienes un codigo "limpio" cualquiera que conozca el ORM lo puede
tomar. Coincido contigo conque el tiempo de desarrollo es mayor porque
tienes la curva de aprendizaje de la herramienta pero una vez que le agarras
el hilo pues incluso puedes decrementar el tiempo de desarrollo. Al llevar
al minimo el codigo de plomeria pues te reduces el tiempo de desarrollo, te
facilitas los mantenimientos y si tienes problemas los puedes identificar
rapidamente.

Para eso usas NHibernate y listo, no te complicas mas la vida. Hay que dejar
un poco de trabajo para los demas, tampoco podemos pretender que Microsoft
nos de todo en la mano, sino la programacion se puede volver un poco
monotona.


Saludos


"Vyacheslav Popov" wrote in message
news:

"Yamil Bracho" escribió en el mensaje
news:%23DWX$

Disculpen que me meta en su discusion pero creo que lo que Popov quiere
hacer es algo como grabar y leer objetos como un todo.
Basicamente ADO.NET es una layer que se monta sobre BD relacionales que
no
son DBMS orientados a objetos.

En efecto :) Y tampoco implementa una abstracción de Correspondencia
Objeto-Relacional (ORM)