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

08/06/2006 - 16:40 por Vyacheslav Popov | Informe spam
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?

Preguntas similare

Leer las respuestas

#21 Alfredo Novoa
09/06/2006 - 03:38 | Informe spam
On Fri, 9 Jun 2006 02:53:07 +0200, "Vyacheslav Popov"
wrote:

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



El modelo objetual no existe como tal. 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. Las dos cosas no tienen nada que ver. No se
pueden comparar, son completamente independientes la una de la otra.

Pues, cualquier aplicación informática tendrá objetos transitorios y
persistentes.



Habría que empezar por definir lo que es un objeto, una aplicación y
un Sistema de Información.

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

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.



Ya, claro, y da lo mismo una cosa que otra, ¿No?

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.

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];
///.



¿Has oido hablar del DataBinding?

Por otro lado esto no es una conversión, sino que simplemente estás
moviendo datos de un sitio a otro.

Otro ejemplo más bonito:

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

¿Se nota la diferencia?



Si, mucho. Intenta juntar y filtrar 4 tablas y agregar datos
agrupandolos por varios campos todo de un solo golpe usando tu
manejadorDePersistencia.

Además has hecho trampa, por que este código no enseña nada y solo
puede buscar por DNI.


Saludos
Respuesta Responder a este mensaje
#22 Alfredo Novoa
09/06/2006 - 03:50 | Informe spam
On Fri, 9 Jun 2006 03:08:42 +0200, "Vyacheslav Popov"
wrote:

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



Sacar partido a las características del lenguaje de programación
típicas de la OO, como la herencia y la ocultación de información.

Esto es compatible con usar un SGBD de forma apropiada.

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.

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


Saludos
Respuesta Responder a este mensaje
#23 Vyacheslav Popov
09/06/2006 - 05:18 | Informe spam
Es bien conocido que el modelo objectual y relacional están divorciados de
por muerte.



El modelo objetual no existe como tal.



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

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.

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)


Pues, cualquier aplicación informática tendrá objetos transitorios y
persistentes.



Habría que empezar por definir lo que es un objeto, una aplicación y
un Sistema de Información.



Clase: descripción de un conjunto de objetos que comparten los mismos
atributos, operaciiones, rlaciones y semántica.
Objeto: instancia de una clase.
Objeto persistente: objeto qeu existe después de que el proceso o hilo que
lo creó deja de existir.
Objeto transitorio: objeto que existe sólo durante la ejecución del hilo o
del proceso que lo creó.
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.


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.

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.



Ya, claro, y da lo mismo una cosa que otra, ¿No?



Abstracción es otra de las ventajas POO.

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%'


Saludos
Respuesta Responder a este mensaje
#24 Eduardo A. Morcillo [MS MVP VB]
09/06/2006 - 05:27 | Informe spam
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).



No llego a ver que tiene que ver eso con ADO.NET. Como primer punto,
DataSet, DataTable y DataRow pueden usarse como base para crear otras clases
donde agregas el codigo que quieras. Un simple ejemplo son los DataSet
tipados que no son ni mas ni menos que clases derivadas de DataSet y sus
amigos. Luego si con lo ultimo te refieres al enlace de datos en los
controles hay que aclarar que el enlace a datos no solo es contra
DataSets/DataTables sino a cualquier objeto que implemente ciertas
interfaces. Y dicho sea de paso, colocar logica de negocios o cualquier otra
cosa en la IU nada tiene que ver con ADO.NET ni el lenguaje sino con el
buen/mal diseño que se haya hecho.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C
Respuesta Responder a este mensaje
#25 Vyacheslav Popov
09/06/2006 - 05:30 | Informe spam
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.

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



En algo estamos de acuerdo !(OO > BD)


Saludos.
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida