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

On Thu, 8 Jun 2006 22:47:48 +0200, "Vyacheslav Popov"
wrote:

Se puede programar un sistema con un lenguaje totalmente orientado a
objetos, como C#, sin hacer programación orientada a objetos (RAD)

Se puede hacer programación RAD orientada a objetos. Siempre será
mejor que hacer programación SAD :)

, pero
resulta muy difícil hacer lo contrario.

¿Y que es lo contrario?

¿Hacer programación OO con C#?

Luego, ADO.NET no soporta programación orientada a objetos.

No me parece un razonamiento muy sólido.


Saludos

On Thu, 8 Jun 2006 11:26:15 -0500, "Harvey Triana"
wrote:

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.

¿Podrías definir estos términos?

-Objeto en si.
-Abstracción de datos.
-Dato inteligente
-Objeto orientado a datos.

¿Soy yo el único al que este párrafo le parece un galimatías?


Saludos

On Thu, 8 Jun 2006 23:40:58 +0200, "Vyacheslav Popov"
wrote:

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

Así que la lógica de negocio es el código que se agrega a las clases
...

Es peligroso intentar repetir de memoria cosas que se han leido por
ahí. Se pueden llegar a escribir tonterías muy grandes.


Saludos

Es bien conocido que el modelo objectual y relacional están divorciados de
por muerte.

Pues, cualquier aplicación informática tendrá objetos transitorios y
persistentes.
Los objetos persistentes tendrán que almacenarse en algún medio de
almacenamiento sea una base de datos, un fichero de texto (xml), o un
archivo binario.

Para suavizar la separación de dos modelos se utiliza la técnica de ORM, de
hecho estamos programado los conversores Objeto-Relacional diariamente
usando ADO.NET.

Un ejemplo:

///.
// Hacemos una conversión objeto - relacional
// Form1 es el objeto de dominio (sólo en ejemplo) y DataSet es un conjunto
de tablas relacionadas

DataSet ds;
sqlDataAdapter da = new SqlDataAdapter("...conexión...", "SELECT * FROM
EMPLEADO WHERE DNI='" + dni + "'");
da.Fill(ds);


// Convertimos
tbDni.Text = ds.Tables[0].Rows[0][0];
tbNombre.Text = ds.Tables[0].Rows[0][1];
tbSueldo.Text = ds.Tables[0].Rows[0][2];
///.


Otro ejemplo más bonito:

Empleado emp = manejadorPersistencia.GetObject(typeof(emp), dni);

¿Se nota la diferencia?



"Alfredo Novoa" escribió en el mensaje
news:

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

Alfredo, ¿que es lo que entiendes por Programación Orientada a Objetos?