Pregunta de arquitectura n capas

On Tue, 6 Mar 2007 12:46:15 -0400, "Luis T"
wrote:

Para mi tener todo controlado por el SGBD es una solucion peor que las
otras
cuando se tiene una aplicacion distribuida.

Todo no, lo que tiene que estar controlado por el Sistema de Gestión
de Bases de Datos es la gestión de las bases de datos.

No hay que ser muy inteligente para saber que cuando hablo de todo
controlado por un SGBD se supone que estamos hablando de gestion de datos.

Aquí eso es mucho suponer.

O sirve para algo mas un SGBD que para gestionar datos?

Pues si que sirve para más cosas. Un SGBD es un caso especial de
servidor de aplicaciones y por lo tanto también sirve para ejecutar
aplicaciones que se pueden beneficiar de todos los otros servicios del
SGBD.

Está visto que esta frase es demasiado compleja para ser comprendida
por el programador medio, pero que le vamos a hacer.

Yo creo que eres vos quien no parece comprender lo que es un sistema
distribuido distinto a un sistema centralizado.

Se bien lo que es un sistema distribuido. Eres tu el que parece
ignorar que existen los SGBD distribuidos que sirven precisamente para
construir sistemas distribuidos.


Saludos

On 6 mrt, 14:41, "Eugenio Serrano" wrote:

Cuando dices:

>Pues para mi está claro que sí hay mejores y peores formas
>de hacer las cosas. Que a veces pueda ser difícil determinar
>que es mejor o peor, lo que parecen implicar estas discusiones,
>es otra questión.

Todo depende del contextoCosas que pueden ser malas bajo determinadas
caracteristicas pueden ser buenas en otra.

Se está hablando de sistemas de información. Ese es el contexto.

Se pueden hacer aplicaciones datacentricas, con toda la logica en el motor
de base de datos y que funcionen tan bien como otra 100% orientada a objetos
donde la logica se maneje en una capa creada para eso.

El contenido de mi mensage tenía tres aspectos:
1) estabas confundiendo aplicación con sistema de información,
2) me pareció que también estás confuso con lo que es un
sistema monolítico y
3) sí hay formas mejores y peores de hacer las cosas.

Tengo que reacionar entonces al punto 3 ? Grrrrr!

Con que criterio dices que uno es malo y el otro es bueno ?
Bien dices que "para ti" esta claro que es mejor o que es peor.

El 'para mi' era solo una actitud 'de diplomacia' que...

Pero lo que para ti puede ser malo, para otro puede ser muy bueno. Es que
son maneras diferentes de encarar un problema.

... vista esta reacción, solo da lugar a embrollos.


Si se está hablando de sistemas de información (ese es el contexto)
las aplicaciones que forman parte del sistema son por definición
datacéntricas. Lo que se llaman 'reglas de negocio' (constraints
de integridad), son (deben ser!) comunes a todas las aplicaciones
en el sistema, y por tanto se tienen que centralizar y compartir.
A nivel de sistema esta centralización se realiza en un SGBD.
Una eventual 'capa donde se maneja la lógica' lo que hace
desde el punto de vista del sistema es encapsular el SGBD original.
Conceptualmente entonces, a nivel de sistema, esta capa *es* el SGBD.

Orientación a objectos tiene su aplicación en el diseño y
programación de los distintos componentes del sistema.
Una aplicación puede haber sido diseñada con OO *y la otra no*,
(repito *y la otra NO*), un middelware puede haber sido diseñado
con OO o no, un SGBD puede haber sido diseñado con OO o no, etc.
Al final forman todos parte de un sistema de información y a ese
nivel las técnicas de diseño y programación de los subsistemas
son totalmente irrelevantes.

Y claro que distintas formas de hacer las cosas pueden funcionar.
Pero eso es decir poco mas que nada.
Puede haber por ejemplo diferencias enormes en escalabilidad.
Está preparado el sistema para aceptar nuevas aplicaciones? p.e.
Una capa de negocio obliga a nuevas aplicaciones a usar las
mismas técnicas y métodos de acceso a los datos que la primera
aplicación ha creido convenientes. Pero lo que para la primera se
haya considerado conveniente no tiene por que serlo para las demás.
Por eso he hecho hincapié arriba en lo de que una aplicación puede
se OO y la otra no. Es mas, estas aplicaciones no tienen ni por que
ser conscientes unas de la existencia de las otras. Estas técnicas
que deberían ser solo relevantes a nivel de subsistema se imponen
entonces en un nivel mas alto a otras partes del sistema lo que
reduce la escalabilidad.

Todo esto aparte de que un capa de negocios al encapsular el SGBD,
también hace desaparecer una interfaz flexible: la estructura
lógica de los datos y un lenguaje de acceso como SQL. En su lugar
nos ofrece otra interfaz de mucho mas bajo nivel: lenguaje
de programación precedimental/OO sin mecanismos para gestionar
datos, donde los programadores de aplicaciones puede 'disfrutar
de los placeres' de navegar por estructuras de datos por medio
de punteros, haciendo la aplicación mas complicada y cara de lo
necesario. Era ese el método de gestionar datos en las aplicaciones
cuando se trabajaba con bases de datos basadas en los modelos de
red y jerárquico, que para repetirlo otra vez más, ha sido
desechado hace décadas.

Saludos,
Carlos

On 6 mrt, 15:32, Alfredo Novoa wrote:

Hola Carlos,

On 6 Mar 2007 05:21:36 -0800, "Carlos M. Calvelo"

wrote:
>On 5 mrt, 15:56, "Eugenio Serrano" wrote:

>> Alfredo propone una aplicacion basada 100% en el motor de bases de datos.

>También propone que "La gente suele confundir las capas del
>sistema con las capas de las aplicaciones."

También no. Lo que propongo (que es lo mismo que dicen los libros
serios) no tiene nada que ver con lo que dice Eugenio.

Hola Alfredo,

Por si existe alguna duda:
Mi mensage a Eugenio era que él mismo estaba confundiendo
aplicación con sistema de información (solo que no he
sido tan explícito). Y eso justo después de que
'alguien' había dicho que la gente suele hacer eso!!!

Saludos,
Carlos

Hola Carlos,

On 6 Mar 2007 10:48:40 -0800, "Carlos M. Calvelo"
wrote:

Por si existe alguna duda:
Mi mensage a Eugenio era que él mismo estaba confundiendo
aplicación con sistema de información (solo que no he
sido tan explícito). Y eso justo después de que
'alguien' había dicho que la gente suele hacer eso!!!

Ah, vale. Ahora lo pillo.

Saludos

Tu dices:

Se está hablando de sistemas de información. Ese es el contexto.

Empezamos mal, para ti tanto una pocket pc, como un sitio web, o como una
aplicacion windows pueden estudiarse como un mismo contexto ??

El contenido de mi mensage tenía tres aspectos:
1) estabas confundiendo aplicación con sistema de información,
2) me pareció que también estás confuso con lo que es un
sistema monolítico y
3) sí hay formas mejores y peores de hacer las cosas.

Tengo que reacionar entonces al punto 3 ? Grrrrr!

De donde "intuyes" que yo confundo un sistema de informacion con una
aplicacion ?
Pues creo que tu lo estas confundiendo.
Claro que las hay, pero hay cosas que se pueden encarar usando distintos
"approach" sin que uno sea mejor que otro.

Si se está hablando de sistemas de información (ese es el contexto)
las aplicaciones que forman parte del sistema son por definición
datacéntricas.

Esa es SOLO tu vision, que si quiero ver a mis clientes como objetos y no
como una tabla ?

Una eventual 'capa donde se maneja la lógica' lo que hace
desde el punto de vista del sistema es encapsular el SGBD original.
Conceptualmente entonces, a nivel de sistema, esta capa *es* el SGBD.

Como puedes decir que una capa de logica es el SGBD ?
Es la primera vez que leo cosa semejante.
Busca "Business Layer" en google y veras que nadie llama a esa capa SGBD.

Orientación a objectos tiene su aplicación en el diseño y
programación de los distintos componentes del sistema.
Una aplicación puede haber sido diseñada con OO *y la otra no*,
(repito *y la otra NO*), un middelware puede haber sido diseñado
con OO o no, un SGBD puede haber sido diseñado con OO o no, etc.
Al final forman todos parte de un sistema de información y a ese
nivel las técnicas de diseño y programación de los subsistemas
son totalmente irrelevantes.

Y esto que tiene que ver con lo que venimos hablando ?
Estabamos hablando de UN Sistema no *del otro*.

Una capa de negocio obliga a nuevas aplicaciones a usar las
mismas técnicas y métodos de acceso a los datos que la primera
aplicación ha creido convenientes.

Realmente no entiendo que quieres decir aqui !
La nueva aplicacion tendra su propia capa de negocios, que puede si quiere
re-utilizar la otra capa o directamente hablar con el motor de bases de
datos.

Todo esto aparte de que un capa de negocios al encapsular el SGBD,
también hace desaparecer una interfaz flexible: la estructura
lógica de los datos y un lenguaje de acceso como SQL. En su lugar
nos ofrece otra interfaz de mucho mas bajo nivel: lenguaje
de programación precedimental/OO sin mecanismos para gestionar
datos, donde los programadores de aplicaciones puede 'disfrutar
de los placeres' de navegar por estructuras de datos por medio
de punteros, haciendo la aplicación mas complicada y cara de lo
necesario. Era ese el método de gestionar datos en las aplicaciones
cuando se trabajaba con bases de datos basadas en los modelos de
red y jerárquico, que para repetirlo otra vez más, ha sido
desechado hace décadas.

Es la primera vez que leo que un lenguaje OO es de mucho mas bajo nivel que
SQL.
:-((

Conclusion:

La misma que en el mail que inicio todo esto: Tu ves el mundo como DATOS,
pero hay algo mas alla, y por lo que se ve tu no puedes, o no quieres verlo.

No quiere decir que sea malo tu punto de vista, es solo una forma de hacer
las cosas, pero hay muchas, muchas otras... Yo respeto tu punto de vista, y
me gustaria que respetes el mio.

Has leido alguna vez a Martin Fowler o Domain Driven Desing ???

Regards / Saludos,
Eugenio Serrano
Microsoft MVP (ASP/ASP.Net)
Solid Quality Mentors
http://www.eugenioserrano.com.ar
if (me.today == me.yesterday) me.tomorrow = null;