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

#21 Alfredo Novoa
23/01/2007 - 16:39 | Informe spam
On 23 Jan 2007 01:09:09 -0800, "Roberto M. Oliva"
wrote:

Es que me parece cojonudo... simplemente descalificas lo que yo digo
porque te da la gana.



No, lo descalifico por que recomiendas prácticas descartadas hace
décadas. Estás difundiendo información incorrecta que puede causar
daños importantes a otras personas.

Tu que sabes lo que yo he aprendido o en lo que
yo he trabajado??



Por lo que escribes es fácil de deducir que de desarrollo de Sistemas
de Información no tienes ni idea, independientemente de en lo que
trabajes.

Hace ya muchos años que deje las aplicaciones basadas en bases de
datos. Dedique muchos esfuerzos a utilizar todos los recursos de una
base de datos: todos aquellos que ahora desestimo.



A saber lo que habrás hecho, pero esto es irrelevante. Lo que escribes
va en contra de toda lógica y de principios científicos firmemente
establecidos.

Decir que es más fácil desarrollar con "objetos de negocio" que con
datasets es una gran mentira.



Has desarrollado con ambas cosas? Yo si he hecho proyectos con ambas
cosas y tambien con lo que tu defiendes.



Si he probado la tontería de los objetos de negocio y los resultados
eran desastrosos. Cosas que eran triviales de hacer con una
herramienta RAD y un SGBD se volvían muy engorrosas confirmando
plenamente lo que predice la teoría.

Resumiendo: Alfredo, te descalificas tu mismo siempre. Yo solo trato de
comentar lo que mi (cortisima, segun tu) experiencia me ha dicho pero,
claro, no tengo la tuya que es suprema!



Yo no hablo mucho de mi experiencia, simplemente estoy contando lo que
ponen los primeros capítulos de los libros de teoría de bases de datos
por si hay alguien que no los ha leido.


Saludos
Respuesta Responder a este mensaje
#22 Roberto M. Oliva
23/01/2007 - 17:18 | Informe spam
Por lo que escribes es fácil de deducir que de desarrollo de Sistemas
de Información no tienes ni idea, independientemente de en lo que
trabajes.




Microsoft Certified Professional en Designing and Implementing
databases with MS SQL Server... hace ya tiempo
Respuesta Responder a este mensaje
#23 Carlos M. Calvelo
23/01/2007 - 21:58 | Informe spam
Hoze (SMM) schreef:
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".



Digamos que las empresas si tienen ese capricho. Unas solo quieren
Powerbuilder, otras solo C# y otras... El cliente manda y algo
inventaremos. Es tecnicamente razonable entonces desarrollar
aplicaciones en un entorno/lenguage que sea independiente
del entorno/lenguaje que quiere el cliente? O vamos por eso a
desarrollar aplicaciones en un SGBD porque a eso, en este caso,
no le dan estas empresas tanta importancia?

De vuelta al problema original:
Cliente 1: "Yo tengo un sistema de GESTION de bases de datos que se
llama SQL Server."

Cliente 2: "Yo tengo un sistema de GESTION de bases de datos que se
llama Oracle."

Tu: "Weeeeeno, aquí tenéis una aplicación que GESTIONA datos"

Brillante! En mi libro eso se llama 'engañar al cliente'.

Saludos,
Carlos
Respuesta Responder a este mensaje
#24 Alfredo Novoa
23/01/2007 - 22:23 | Informe spam
On 23 Jan 2007 08:18:03 -0800, "Roberto M. Oliva"
wrote:

Por lo que escribes es fácil de deducir que de desarrollo de Sistemas
de Información no tienes ni idea, independientemente de en lo que
trabajes.




Microsoft Certified Professional en Designing and Implementing
databases with MS SQL Server... hace ya tiempo



Pues vaya cosa.
Respuesta Responder a este mensaje
#25 Hoze
24/01/2007 - 11:07 | Informe spam
A mí no me lo parece... Se puede aprovechar mucho las prestaciones de un
SGBD sin tener que vincularte a él. Igual en mi primer post me excedí
diciendo que un SGBD no es más que un contenedor de datos, es cierto y
evidente que no es así, pero bajo mi criterio no soy partidario de que el
SGBD intervenga en la GESTIÓN de la lógica de los datos, y con esto no me
refiero a integridad referencial, validación de restricciones, etc, sino a
la lógica que une a las distintas entidades de tu aplicación.

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