Extraído de otro hilo: gestión de datos y objetos de negocio

Hola,

On Mon, 22 Jan 2007 17:40:54 +0100, "Hoze" wrote:

Igual esto me pilla un poco descolocado o no he sido capaz de entender el
thread, pero decís que el modelo de aplicaciones basado en objetos de
negocio no es válido con vs 2005?

Ni con VS 2005 ni con nada.

¿Por qué?

Por que en el mejor de los casos los objetos de negocio no aportan
nada, y en la mayoría de los casos conducen a auténticos disparates
como gestionar los datos desde las aplicaciones.

¿Cómo proponéis que se diseñe una aplicación sin jerarquías de objetos en el
acceso a datos

En el acceso a datos puede haber las jerarquías que quieras. Por
ejemplo SqlConnection desciende de DbConnection y no hay nada de malo
en ello.

, en la gestión de maestros, etc?

Si te refieres a las relaciones maestro detalle para eso no tienes que
crear nuevas clases.

¿Qué responsabilidad y qué
grado de dependencia de la bbdd estáis dando a la base de datos?

Esta frase no tiene sentido.

¿Qué aporta un dataset?

Facilita la presentación de los datos y es una clase reutilizable.
Aunque se podría mejorar muchísimo.

¿Qué ventajas da en cuanto a abstracción y gestión de
los datos a las que pueda dar un conjunto de objetos de negocio que acceden
al SGBD utilizando datareaders?

Las aplicaciones no deben de abstraer ni gestionar los datos. Para eso
está el SGBD.

¿Cómo se "compensan" los inconvenientes de un dataset?:
- Rigidez

No se a que te refieres. Los datasets son mucho más flexibles que los
"objetos de negocio".

- Problemas con las actualizaciones--> ¿integridad referencial?

No hay problema si se trabaja en modo conectado.

- Gestión de filtros de datos

Los datos se filtran con consultas SQL.

- Problemas de volumen y velocidad en recuperaciones masivas de
registros..

Este problema lo tienes uses lo que uses. Para solucionar esto está la
paginación.


Saludos

Hola!

Yo creo que se habla segun lo que cree cada uno que es mejor. Y hay
gente por aqui que prefiere basar toda la logica de negocio en la base
de datos.
Yo por mi experiencia siempre prefiero tratar la logica de negocio con
programacion orientada a objetos. Modelo en la base de datos la
estructura basica de las entidades: campos unicos, indices, integridad
referencial, etc. Pero no suelo tener ni vistas ni procedimientos
almacenados ni triggers.
Tampoco uso DataSets. Nunca he visto el beneficio de su escalabilidad
en los proyectos en los que he trabajado, por lo que he preferido tirar
por un software mas facil de desarrollar que a uno que sea muy
escalable. Pero esto depende del entorno final del proyecto.
Si te sirve de algo, mi experiencia me ha decantado por el desarrollo
de la capa de negocio con patrones de diseño. Sobre todo: ActiveRecord
y utilizando librerias ya funcionales: NHibernate y MonoRail
ActiveRecord.

Esta es mi experiencia y ha sido muy positiva... y para nada quiere
decir que sea la unica. Todo esto es caldo de cultivo para opiniones
muy dispares (mas o menos respetables) de otras personas.

Un saludo
Roberto M. Oliva


Hoze ha escrito:

Hola a todos... en el thread "Programación orientada a objetos" discutís
algo levemente que no he sido capaz de entender. En determinado momento se
dice:

>> Qué utilizamos entonces, entidades de
>>lógica de negocio ??

>No, eso es mucho peor que los datasets.


Igual esto me pilla un poco descolocado o no he sido capaz de entender el
thread, pero decís que el modelo de aplicaciones basado en objetos de
negocio no es válido con vs 2005? ¿Por qué?

¿Cómo proponéis que se diseñe una aplicación sin jerarquías de objetos en el
acceso a datos, en la gestión de maestros, etc?¿Qué responsabilidad y qué
grado de dependencia de la bbdd estáis dando a la base de datos? Ojo, hablo
de aplicación como un sistema complejo, no de un "hola mundo".

¿Qué aporta un dataset?¿Qué ventajas da en cuanto a abstracción y gestión de
los datos a las que pueda dar un conjunto de objetos de negocio que acceden
al SGBD utilizando datareaders?

¿Cómo se "compensan" los inconvenientes de un dataset?:
- Rigidez
- Problemas con las actualizaciones--> ¿integridad referencial?
- Gestión de filtros de datos
- Problemas de volumen y velocidad en recuperaciones masivas de
registros..


¿¿???


Gracias

Yo trabajo en la misma línea que tú. No soy partidario de utilizar el SGBD
para darle lógica a una aplicación. Siempre he basado mis aplicaciones en
modelos de objetos y la lógica de negocio la diseño e implemento en mi soft,
no en la base de datos. Pienso que es un modelo más flexible: independiza mi
desarrollo de la base de datos, me permite trabajar en distintos entornos y
con distintas configuraciones hardware y software. Los objetos de negocio
mantienen la lógica de la aplicación y la base de datos se asegura de que la
información se guarda y mantiene correctamente. Igual que tú, hago poco uso
de los datasets. Veo sus ventajas para determinados casos, pero pienso que
se hace un uso más eficiente del SGBD sin datasets... o vale, sin
dataadapters, siendo tú quien gestione el acceso a datos. Yo también uso
Hibernate (hasta ahora en Java) y es una solución muy buena.

No lo sé, hay gustos para todo. Pero no pienso que el desarrollo basado en
objetos de negocio sea una alternativa mala...

"Roberto M. Oliva" wrote in message
news:

Hola!

Yo creo que se habla segun lo que cree cada uno que es mejor. Y hay
gente por aqui que prefiere basar toda la logica de negocio en la base
de datos.

Pero no suelo tener ni vistas ni procedimientos
almacenados ni triggers.

Si dices eso en un foro de sql server te dirán que estás muy mal :)

Tampoco uso DataSets. Nunca he visto el beneficio de su escalabilidad
en los proyectos en los que he trabajado, por lo que he preferido tirar
por un software mas facil de desarrollar que a uno que sea muy
escalable. Pero esto depende del entorno final del proyecto.

He visto de varios que dicen que no usan DataSets. Yo que estoy comenzando
en C# me confunde. Como uno hace para trabajar sin datasets o dataadapters?
Que ventajas tiene?

Gracias

"Alfredo Novoa" wrote in message
news:

[...]

¿Qué responsabilidad y qué
grado de dependencia de la bbdd estáis dando a la base de datos?

Esta frase no tiene sentido.

Sí lo tiene. El grado de dependencia de la BBDD depende del uso de SPs,
tipos de datos específicos, funciones, lenguaje de los SP's, definición de
las particiones de la base de datos, gestión de seguridad, etc...

¿Qué aporta un dataset?

Facilita la presentación de los datos y es una clase reutilizable.
Aunque se podría mejorar muchísimo.

Y ya.

¿Qué ventajas da en cuanto a abstracción y gestión de
los datos a las que pueda dar un conjunto de objetos de negocio que
acceden
al SGBD utilizando datareaders?

Las aplicaciones no deben de abstraer ni gestionar los datos. Para eso
está el SGBD.

No estoy de acuerdo. El SGBD es un almacén de datos, y tu desarrollo, a
niveles superiores, tiene que estar completamente aislada de:
- Qué SGBD se utiliza como almacén de datos
- Cómo están definidos estos datos
- Cómo se recuperan y cómo se almacenan

¿Cómo se "compensan" los inconvenientes de un dataset?:
- Rigidez

No se a que te refieres. Los datasets son mucho más flexibles que los
"objetos de negocio".

- Problemas con las actualizaciones--> ¿integridad referencial?

No hay problema si se trabaja en modo conectado.

- Gestión de filtros de datos

Los datos se filtran con consultas SQL.

Claro, cuando los recuperas, pero luego ponte a trabajar con ellos...

- Problemas de volumen y velocidad en recuperaciones masivas de
registros..

Este problema lo tienes uses lo que uses. Para solucionar esto está la
paginación.

Ya lo sé, pero si tengo que preocuparme ya de la carga y la
paginación...

Saludos