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

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.

Lo que quiero decir es que, si la responsabilidad de hacer un objeto
persistente se coloca en Experto nos lleva a problemas de cohesión,
acoplamiento y duplicación. Si usamos LINQ el diseño consistirá en usar una
superclase Table de la que "heredan" todos los objetos persistente, esto
acopla altamente los objetos del dominio a un servicio del nivel tecnológico
particular y mezcla diferentes aspectos de la arquitectura.
Todos estos problemas indican la violación de un principio arquitectural
básico: diseñe separando los principales aspectos del sistema.

Saludos.

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.

Hoy en dia sí.
Precisamente por esta razón se invento la técnica ORM, para hacer puente
entre objetos y datos planos.

El mundo de objetos y las bases de datos relacionales seguirán siendo
incompatibles.

Un ORM es algo que se coloca delante de un sofisticado SGBD SQL y lo
convierte en un primitivo procesador de registros. Es como poner un
televisor dentro de una caja de madera. Todavía lo puedes escuchar un
poco.

El proyecto LINQ se basa en la técnica ORM y algebra relacional se integra
en C#.

Lo único común de datos relacionales y objetos son los diagramas del dominio
y diagramas E-R.

En fin, gracias por tus respuestas.

On Fri, 9 Jun 2006 19:47:58 +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.

Hoy en dia sí.
Precisamente por esta razón se invento la técnica ORM, para hacer puente
entre objetos y datos planos.

No, no lo has entendido.

No hay ni datos planos ni datos gordos ni datos curvos.

El OOAD no sirve para diseñar Sistemas de Información, por que el
único bloque de construcción que emplea es la clase (el tipo escalar),
y esto es demasiado primitivo.

El Modelo Relacional es la mejor forma que se conoce de gestionar
datos, y el OOAD no lo tiene en cuenta para nada. Esto lo invalida
completamente para el diseño de Sistemas de Información.


Saludos
Alfredo

Hola Yamil,

On Fri, 9 Jun 2006 09:31:01 -0400, "Yamil Bracho"
wrote:

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

Pues VS 2005 ya resuelve todo esto bastante bien, y Delphi, Power
Builder y otros ya lo resolvían hace muchos años.

La mejora del Hardware mejora cualquier cosa pero si debo hacer un
mantenimiento prefiero algo donde tengo que invertirle menos tiempo..

Y eso no es el ORM. El ORM además de que puede llegar a ser muchísimo
más lento es mucho más trabajoso.

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 ?

No, no me parece. Esto es una falacia conocida como "argumentum ad
populum".

http://es.wikipedia.org/wiki/Argumentum_ad_populum
http://es.wikipedia.org/wiki/Falacia

Que se use mucho no quiere decir que sea bueno, y menos en esta
profesión.

Un buen profesional debería de ser capaz de evaluar por si mismo si un
producto es bueno o malo en lugar de tener que seguir al rebaño.

Ademas no tiene un marketing detras de ello
ya que es un proyecto gratis..

Eso no importa, hay muchas formas de marketing gratuito. Por ejemplo
lo que tu mismo acabas de hacer.

R. Si tienes un codigo "limpio" cualquiera que conozca el ORM lo puede
tomar.

No, eso depende de muchas más cosas. Por ejemplo el código puede estar
todo lo "limpio" que quieras, pero si está lleno de laberintos de
punteros no habrá quien le pueda meter mano.

Una consulta SQL es mucho más fácil de interpretar que su equivalente
procedimental.

Un grid que se llena con una SQL es mucho más fácil de entender que un
grid que se llena con un lio de saltos, bucles y sumas.


Saludos
Alfredo