Pregunta de arquitectura n capas

Hola Carlos,

On 6 Mar 2007 10:44:17 -0800, "Carlos M. Calvelo"
wrote:

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.

Esto en el fondo es cierto. Lo que para el cliente puede ser malo,
para un proveedor desaprensivo puede ser muy bueno.

Tampoco son raros los casos de programadores que crean código
ininteligible y son recompensados por ello. Yo lo he visto unas
cuantas veces.

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.

Y un sistema de información es datocéntrico por naturaleza. Por algo
la informática se llama como se llama.

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.

Siempre que esa capa esté fuera de las aplicaciones.

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.

Cierto, al nivel de sistema de información la OO no tiene ninguna
aplicación.

Y claro que distintas formas de hacer las cosas pueden funcionar.
Pero eso es decir poco mas que nada.

Es una falacia clásica por aquí. Supongo que se puede considerar como
una variante de la falacia del hombre paja.

A dice: la forma O de hacer las cosas es mala.
E dice: la forma O de hacer las cosas funciona, luego A está
equivocado.

Pero A nunca ha dicho que la forma O no funciona.

Puede haber por ejemplo diferencias enormes en escalabilidad.

Y en coste de desarrollo, mantenibilidad, eficiencia, etc, etc.

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.

Mejor sería que hiciesen bien su trabajo y se fuesen a casa a hacer
sudokus.


Saludos
Alfredo

On 6 mrt, 21:10, "Eugenio Serrano" wrote:

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

Totalmente irrelevante para lo que se está hablando.
Por lo menos yo.

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

De esto que has escrito:
de datos."

Y no lo "intuyo"; lo das tu a saber.

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.

Claro... cualquier "approach" que cualquier charlatán se invente
"no es mejor ni peor" que otros. Ya está. Porque tu lo dices!
Y yo no puedo tratar de determinar si uno es mejor o peor.
Vaya! Vaya! Cualquier "approach" está bien entonces!!??

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

Pues en ese caso yo te diría que peor para tí! Y si eso es lo que
te parece mejor diría que no te has enterado de, o no has entendido,
lo que ha pasado en los últimos 30 y varios años en el campo del data
management. También te diría que que no estas solo en tu postura y
que la gran mayoría está contigo.

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

Yo digo que si encapsulas un SGBD detrás de una capa de lógica
entonces conceptualmente esa capa es el SGBD porque esa capa
solo va a realizar funciones que son responsabilidad del SGBD.
Estarías realizando un SGBD bastante pobre encapsulando otro mucho
mas potente.

Busca "Business Layer" en google y veras que nadie llama a esa capa SGBD.

Busca "Business Rules" y que es lo que representan en términos de
lógica y a lo mejor encuentras un explicación de lo que son un
DataBase Management System y que es una base de datos.

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

Tiene que ver que el OO no es para la gestión de datos; es
para otras cosas.

Estabamos hablando de UN Sistema no *del otro*.

Yo estoy hablando de un sistema de informacion.
No hay tal *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.

BRILLANTE! Aquí casi me da un blackout!

O sea que una aplicación tiene su capa de negocios y otra aplicación
puede tener otra u una tercera puede conectarse directamente al
SGBD, etc... y todas comparten la misma base de datos ???
Aquí apaga y vámonos!!!

Yo me pregunto:Y que hacen todas estas capas de nogocio por las
cuales algunas aplicaciones ni estan obligadas a pasar para llegar
a los datos??? Poner café?
Quien garantiza la consistencia de todos estos sistemas de reglas?
Quien garantiza que los datos sean consistentes con todas los
constraints de integridad que se representan en las capa(S)! de
negocios?

No busques solo "Business Rules" y lo que representan, sino también
"data integrity" y "integrity constraints".

>> 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.
:-((

:) En eso tampoco estás solo.

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. Yo no veo el mundo como datos! Pero en un sistema de información
son bastante importantes, lo mas importante, y guardar su integridad
es la quizás la responsablidad mas seria que tienen los SGBDs y los
diseñadores de bases de datos.
Para las organizaciones, sobre todo medianas y grandes, que utilizan
estos sistemas los datos son un tesoro! que antes de perderlo aun
tiran todas las aplicaciones por la ventana, por que el valor
económico de estas es ridículo comparado con lo que representan
los datos.

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.

Me puedes exigir! que te respete a ti como persona.
Pero me estás diciendo que si no estoy de acuerdo con tus ideas y
que si estoy convencido de que no tienen fundamento no puedo
atacarlas? Puntualizo aquí que no estamos hablando de política
o religión. Tu no quieres llamar 'malo' mi punto de vista. Bien.
Yo si digo que tu punto de vista no es 'malo' en si; pero que desde
hace ya tiempo hay 'formas de hacer las cosas' mejores y en ese
sentido tu punto de vista es uno equivocado y está mal.
Te he faltado al respeto? Espero que no!

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

Tengo yo mucho que leer. La pila no hace mas que crecer.
Durante demasiados años ya he perdido yo demasiado tiempo leyendo
tonterías del momento. Sin embargo en los últimos años las
prioridades en cuanto a lo que vale la pena leer se ponen cada vez
mas claras. Este señor no aparece en la lista.
Pero gracias por el consejo. Yo a ti te aconsejo no leerlo.

Saludos,
Carlos

Carlos me quedo con esta frase tuya...

Y si eso es lo que te parece mejor diría que no te has enterado de, o no
has entendido,
lo que ha pasado en los últimos 30 y varios años en el campo del data
management. También te diría que que no estas solo en tu postura y
que la gran mayoría está contigo.

Ya entiendo, tu eres de los "pocos elegidos" que si se ha enterado que ha
pasado los ultimos 30 años en el campo de la computación y todos los demás,
la gran mayoria (tu lo has dicho) estan conmigo...

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;

Hola Carlos

Creo que una parte de lo que dices totalmente cierta:
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.

Pero otra es totalmente arbitraria:

A nivel de sistema esta centralización se realiza en un SGBD.

En cuanto a:

son (deben ser!) comunes a todas las aplicaciones

Nadie dice que eso debe ser implementado en un SGBD.

Te voy a dar un claro ejemplo de esto, un cajero automático.
Creo que muchos de nosotros no hemos creado el software para una red de
cajeros, pero seguramente muchos de nosotros si hemos retirado dibero,
efectuado pagos, consultado saldos utilizando un cajero automatico.

Bueno, todas esas operaciones están centralizadas en el operador de la Red,
en Argentina tenemos la Red BAPRO, Link, Banelco y algunas otras.

Las operaciones de cajero se realizan centralizadas en la Red,
descentralizadas por cada banco afilido a la red.
En este ejemplo no existe un SGBD, las reglas de negocio se implementan en
el administrador de las redes, los cajeros automaticos manejan transacciones
recurriendo a servicios centralizados en los administradores de las redes
respectivas y es alli donde se ejecutan las reglas de negocio.

Es una arquitectura orientada a servicios en donde cada Banco participante
de cada Red consume servicios para atender a clientes de otros Bancos y
brinda servicios para Clientes de otros Bancos que utilizan los cajeros
automaticos propios.

En los bancos encontrarás muchos ejemplos de este tipo.
Otro ejemplo concreto, la contabilidad de un banco.
Toda la operatoria bancaria las oficinas administrativas y las operaciones
efectuadas en sucursales deben ser contabilizadas.
Imagina la cantidad e sistemas que interactuan con la contabilidad:

Compras
Creditos personales
Creditos de todo tipo
Operaciones de cambio en moneda extranjera
Cuentas de cheques
Depositos
Etc, etc

Bueno esos sistemas tambien se ejecutan en forma descentralizada.
Como se contabiliza todas esas operatorias?

El core contable del Banco expone servicios contables
Esos servicios contables son consunidos por las aplicaciones especificas de
cada operatoria.
Algunas de esas aplicaciones por supuesto tienen y utilizan algun SGBD, pero
sin embargo la contabilidad no se registra en esos repositorios.

Las reglas de negocio puedes implementarlas donde gustes, SGBD si te gusta y
te sirve, una capa de negocios orientada a objeto, o cualquier otra cosa.

Volviendo a:

A nivel de sistema esta centralización se realiza en un SGBD.

Creo que das opiniones como verdades biblicas :-))
Tal vez sea bueno que comprendas que hay otra forma de hacer las cosas y esa
forma existe como fruto de la necesidad de resolver problemas que no se
pueden resolver con tecnologia o arquitecturas tradicionales.

Saudos

Daniel A. Calvin
MCP


"Carlos M. Calvelo" wrote:

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

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.

Sistema distribuido es algo mas general que SGBD distribuido y en aquel
puede darse que algunos nodos no necesariamente tengan el mismo SGBD (aun
distribuido) o hasta ni tengan SGBD propiamente.

Luis, eso es un concepto demasiado avanzado que Alfredito no va a entender.
Revisa sus hilos y veras que ese señor no ha pasado de una teoria aerea de
bases de datos de hace 30 años. Yo dudo que haya hecho un programa en su
vida.