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

Programar es divertido, pero desarrollar software de calidad es difícil.
Sistemas de objetos

No sé bien de que super lenguaje hablas ¿-?

Lenguaje no, programación orientada a objetos.

La capa media hace una abstraccion transparente con ADO.NET contra la
bd... El frontal no tiene que hacer nada con ADO.NET. De otro lado,
naturalmente la persitencia esta en la bd. No veo porque complicar más
esta simpleza.

La arquitectura de software, tiene que ver con el diseño y la implementación
de estructuras de software de alto nivel. Es el resultado de ensamblar un
cierto número de elementos arquitectónicos de forma adecuada para satisfacer
la mayor funcionalidad y requerimientos de desempeño de un sistema, así como
requerimientos no funcionales, como la confiabilidad, escalabilidad,
portabilidad, y disponibilidad. -Kruchten, Philippe

En programación orientada a objetos, la lógica de negocios es el código
específico que se agrega a las clases. En una aplicación bien diseñada, con
un rico Modelo del dominio, la mayoría de la lógica de negocios debería
estar en las clases del dominio (no en las interfaces de usuario).

Luego, ADO.NET no permite aprovechar la potencia de programación orientada a
objetos.

Saludes,
<Harvey Triana />


"Vyacheslav Popov" escribió en el
mensaje news:

Es que ADO.NET son objetos en si. ADO.NET Suministra abstracción de
datos,
no datos inteligentes. Si deseas objetos orientados a datos debes
programarlos con el lenguaje, es decir C#. De hecho estos objetos es lo
que se conoce como capa media.

Tienes toda la razón: el responsable de hacer los objetos del la capa de
dominio persistes, es la capa de persistencia. La capa de persistencia, a
su vez, prestará servicios a la capa de acceso a datos (ADO.NET). Pero
todo esto me compromete implementar la capa encargada de hacer
correspondencia de registros a objetos (mapping) que es precisamente a lo
que me refiero. Hay una abstracción muy grande entre el modelo de dominio
y ADO.NET, sin embargo, la capa de interfaz esta ligada a ella.

En mi opinión, desde el punto de vista de la programación orientada a
objetos, la arquitectura de plataforma .NET no es adecuada.

"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)

Una de las ventajas que le veo a un ORM es que te queda el codigo mas
limpio, mas OOP, y esto te lleva a un mantenimiento mas sencillo y si por
otra parte es rendimiento se ve afectado pero quizas alli se puedan hacer
algunas mejoras en el Hardware del servidor de BD o aplicando un buen diseno
de BD...
En el mundo de Java Hibernate es casi el estandard y hay una version para
Net, tambine gratis y que quizas valga la pena echarle una mirada y usarlo
en algun proyecto..
"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)

On Thu, 8 Jun 2006 23:45:34 +0200, "Vyacheslav Popov"
wrote:

"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)

Y no lo hace por buenas razones. Está más que demostrado que la OO se
lleva fatal con las bases de datos.

Podeis leer aquí lo que dice el creador de C++:

Many years ago, the INCITS H2 Database Standards Committee(nee ANSI
X3H2 Database Standards Committee) had a meeting in Rapid City, South
Dakota. We had Mount Rushmore and Bjarne Stroustrup as special
attractions. Mr. Stroustrup did his slide show about Bell Labs
inventing C++ and OO programming for us and we got to ask questions.

One of the questions was how we should put OO stuff into SQL. His
answer was that Bells Labs, with all their talent, had tried four
different approaches to this problem and come the conclusion that you
should not do it. OO was great for programming but deadly for data.

http://groups.google.com/group/comp...5f85ef285b


Saludos

On Thu, 8 Jun 2006 19:21:17 -0400, "Yamil Bracho"
wrote:

Una de las ventajas que le veo a un ORM es que te queda el codigo mas
limpio, mas OOP, y esto te lleva a un mantenimiento mas sencillo y si por
otra parte es rendimiento se ve afectado pero quizas alli se puedan hacer
algunas mejoras en el Hardware del servidor de BD o aplicando un buen diseno
de BD...

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.

En el mundo de Java Hibernate es casi el estandard

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

y hay una version para
Net, tambine gratis y que quizas valga la pena echarle una mirada y usarlo
en algun proyecto..

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.


Saludos