Últimos mensajes - Powered by IBM

Palabras claves

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

22/01/2007 - 17:40 por Hoze | Informe spam

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

Siga el debate

33 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#16 Hoze \(SMM\)

23/01/2007 - 11:09 | Informe spam

Pues a mí no me lo parece, ya que cuando desarrollas un producto y mandas
tus comerciales a venderlo por las tierras de Dios, nadie te dice... "uy, en
mi empresa tenemos programas con PowerBuilder, si el tuyo es c# no lo
quiero".

Responder a este mensaje

#17 Roberto M. Oliva

23/01/2007 - 11:18 | Informe spam

Hola Rogelio!

Rogelio ha escrito:

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

Ya, ya lo se...

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

Seria utilizando consultas directas a la base de datos (comandos). En
ciertas ocasiones es necesario utilizar DataSets o DataReaders para
recibir datos. De todas formas lo suyo es encapsular estas consultas en
objetos de negocio.

Yo utilizo NHibernate que te permite definir como son los objetos de
negocio y él se encarga de mapearlos contra la bases de datos,
independizandote de la misma. Tambien te permite especificar las
relaciones y mantenerlas automáticamente. Es lo que se denomina ORM
(denostado en el mismo foro de sql server).
Porque utilizo este sistema y no trabajo directamente contra la base de
datos? Porque esto me permite programar testeos a diferentes niveles:
unitarios, funcionales y de integracion. Y esto me permite hacer
evolucionar la aplicacion con bastante seguridad (cosa que metiendo la
logica de negocio en la BD, segun mi experiencia, me ha reusltado
bastante engorrosa). Aparte de claridad de codigo, mantenibilidad,
escalabilidad, etc.

Saludos
Roberto M. Oliva

Gracias

Responder a este mensaje

#18 Rogelio

23/01/2007 - 13:51 | Informe spam

Algo que veo reiterado en algunos mensajes es que los datos no se deben
gestionar en las aplicaciones. No veo claro el alcance del termino
"gestionar". Tener una clase tipada que me represente una entidad 'cliente'
de la base de datos sería también gestionar datos en la aplicacion ?
No es correcto entonces tener la estructura de las tablas (solo eso)
mapeadas a clases?

Responder a este mensaje

#19 Alfredo Novoa

23/01/2007 - 16:14 | Informe spam

On Tue, 23 Jan 2007 08:51:00 -0400, "Rogelio"
wrote:

Algo que veo reiterado en algunos mensajes es que los datos no se deben
gestionar en las aplicaciones. No veo claro el alcance del termino
"gestionar". Tener una clase tipada que me represente una entidad 'cliente'
de la base de datos sería también gestionar datos en la aplicacion ?

No.

No es correcto entonces tener la estructura de las tablas (solo eso)
mapeadas a clases?

Incorrecto no es, el caso es para que las usas y si sirven para algo.

Saludos

Responder a este mensaje

#20 Alfredo Novoa

23/01/2007 - 16:21 | Informe spam

On 23 Jan 2007 02:18:38 -0800, "Roberto M. Oliva"
wrote:

Yo utilizo NHibernate que te permite definir como son los objetos de
negocio y él se encarga de mapearlos contra la bases de datos,
independizandote de la misma. Tambien te permite especificar las
relaciones y mantenerlas automáticamente. Es lo que se denomina ORM
(denostado en el mismo foro de sql server).

Se ve que por allí entienden algo de bases de datos.

Porque utilizo este sistema y no trabajo directamente contra la base de
datos? Porque esto me permite programar testeos a diferentes niveles:
unitarios, funcionales y de integracion. Y esto me permite hacer
evolucionar la aplicacion con bastante seguridad (cosa que metiendo la
logica de negocio en la BD, segun mi experiencia, me ha reusltado
bastante engorrosa).

No habrás sabido, por que en realidad es mucho más fácil

Aparte de claridad de codigo, mantenibilidad,
escalabilidad, etc.

Y esto igual. Cualquiera sabe que el código declarativo es mucho más
claro y fácil de mantener que el procedimental. La centralización de
la comprobación de la integridad de los datos también ayuda mucho al
mantenimiento y la escalabilidad.

Saludos

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4 5 6 7

Busqueda sugerida