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

Preguntas similare

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".
#17 Roberto M. Oliva
23/01/2007 - 11:18 | Informe spam
Hola Rogelio!

Rogelio ha escrito:
Mostrar la cita
Ya, ya lo se...

Mostrar la cita
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



Mostrar la cita
#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?
#19 Alfredo Novoa
23/01/2007 - 16:14 | Informe spam
On Tue, 23 Jan 2007 08:51:00 -0400, "Rogelio"
wrote:

Mostrar la cita
No.

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


Saludos
#20 Alfredo Novoa
23/01/2007 - 16:21 | Informe spam
On 23 Jan 2007 02:18:38 -0800, "Roberto M. Oliva"
wrote:

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

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

Mostrar la cita
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
Ads by Google
Search Busqueda sugerida