Ayuda modelo de tres capas...

On Fri, 1 Jul 2005 17:45:49 +0200, "Carlos García-Carazo"
<sharpmanArrobaqueterroba_terra.es> wrote:

Yo casi que apostaría que
así vas a tardar más, ya que es tu primera gran experiencia con una aplicación encapsulada en
objetos de negocio, seguramente vas a confundir cosas, vas a tropezar con problemas derivados
del aislamiento del acceso al SGBD que no podrás prever, y a lo que vamos, tu labor como
desarrollador va a estar en entredicho desde el punto de vista de los usuarios, que sólo saben
opinar sobre "pantallas".

Yo me apostaría cualquier cosa con la seguridad de ganar ;-). He visto
a mucha gente tropezar en esa piedra, y yo también lo hice hace años.

Para alguien que provenga de crear aplicaciones Cliente/Servidor
usando herramientas RAD, la pérdida de productividad es evidente e
impresionante.

Encapsular cada acceso a BD con procedimientos
almacenados como medida de "independencia entre capas" no me convence, sencillamente porque
no veo esas grandes ventajas por ningún lado y estás añadiendo un nivel de indirección que creo
que va más a complicarte la vida que otra cosa.

Es que resulta que la capa del diseño relacional ya es un nivel de
indirección. Lo que hacen es añadir un nivel extra innecesario que no
aporta valor.

Esto viene de no entender los que es realmente un SGBD y de
confundirlo con un mecanismo de persistencia. Un error muy habitual en
los libros OO de supermercado.

Como resumen final, creo que la mejor metodología (para alguien "no experto") es el sentido común.

Ya, el problema es que el sentido común es el menos común de los
sentidos, pero todo el mundo cree tener suficiente :)

Habrá a quién usar objetos de negocio y seguir al pie de la letra la
metodología RUP o las ideas de Scott Ambler le parezca de sentido
común X-D

Y más si no tienes un jefe experto que te exija usar UML, tres capas puras etc.
Vas a ser evaluado por gente a la que esas cosa ni le van ni le vienen, así que yo creo que prima el
tiempo de desarrollo y la ausencia de errores. Con el tiempo sacarás tu propia metodología, que
probablemente coja cosas de aquí y de allá.

Si, eso está claro. Nunca hay que tomarse las metodologías al pie de
la letra, la actitud que hay que tener es: vamos a ver si podemos
sacar algo útil de aquí. Además cada proyecto necesita su propia
metodología particular. Las cosas no son tan sencillas como las pintan
algunos "gurús".


Saludos

P.D. Que alivio ver que en estos grupos hay alguien que es capaz de
pensar por si mismo

Hola Carlos agradezco tus cometarios y me parece conveniente lo que me dices,
creo que en general lo estoy haciendo como tu me lo sugieres. Saludos





"Carlos García-Carazo" wrote:

Hola,
ya te han dado dos puntos de vista muy argumentados y me gustaría aportar el mío
basado en mi experiencia personal. Esta experiencia no es de muchos años
a diferencia de la de las personas que han contestado, pero creo que es interesante
en el sentido que muestra el punto de vista de un programador normal, que debe
afrontar un gran reto adoptando una "forma" de hacer las cosas que no domina a la
perfección.

A mí y al equipo con el que trabajé, los objetos de negocio nos dieron muchos dolores
de cabeza. Primero, porque para entender bién esta metodología hace falta leer mucha
documentación: que si UML, que si RUP, patrones de diseño básicos, arquitectura de
capas, esquema persistente... se pueden obviar muchas cosas, pero en ese
caso es muy fácil confundir conceptos y aprender mal la metodología. Segundo, porque aunque
tú hayas conseguido dominar lo básico de cada cosa, el compañero de al lado puede haber
entendido algo distinto, con lo que al unificar clases habran problemas. Tercero, porque
normalmente necesitas herramientas de apoyo (por lo menos alguna de modelado UML)
que te pueden ralentizar el desarrollo más que ayudarte, sobre todo cuando ya tienes
buena parte de la aplicación escrita y vas modificando código sobre la marcha.

Bueno, tampoco voy a seguir enumerando porque realmente sólo quiero decir que esta metodología
tan moderna y tan de moda da muchos problemas al que se mete de lleno siendo alguien "normal".
No puedo hablar del caso de un experto en el modelado de objetos de negocio sencillamente
porque yo no lo soy.

Como has comentado en otro post, estás tú sólo como desarrollador. En ese caso yo no me la
jugaría haciendo un sistema "puro" con objetos de negocio bién encapsulados, con tratamiento
aislado de su persistencia y siguiendo al pie de la letra la metodología. Yo casi que apostaría que
así vas a tardar más, ya que es tu primera gran experiencia con una aplicación encapsulada en
objetos de negocio, seguramente vas a confundir cosas, vas a tropezar con problemas derivados
del aislamiento del acceso al SGBD que no podrás prever, y a lo que vamos, tu labor como
desarrollador va a estar en entredicho desde el punto de vista de los usuarios, que sólo saben
opinar sobre "pantallas".

Con esto, y para no alargarme más, no digo que en tu lugar no haría nada que forzase en exceso
tu forma de programar habitual. Creo que puedes hacer objetos "de negocio" con un significado
lógico dentro de la aplicación, pero también creo que se puede lanzar código de acceso
a BD desde esos objetos sin ningún problema. Encapsular cada acceso a BD con procedimientos
almacenados como medida de "independencia entre capas" no me convence, sencillamente porque
no veo esas grandes ventajas por ningún lado y estás añadiendo un nivel de indirección que creo
que va más a complicarte la vida que otra cosa.

Como resumen final, creo que la mejor metodología (para alguien "no experto") es el sentido común.
Y más si no tienes un jefe experto que te exija usar UML, tres capas puras etc.
Vas a ser evaluado por gente a la que esas cosa ni le van ni le vienen, así que yo creo que prima el
tiempo de desarrollo y la ausencia de errores. Con el tiempo sacarás tu propia metodología, que
probablemente coja cosas de aquí y de allá.

Saludos y mucha suerte con lo que elijas.

PD: en mi experiencia, el equipo sufrió un GRAN retraso al no existir grandes expertos ni en O.N para
no equivocarse, ni en SGBD para elegir el otro camino.

re:

A Hermann Goering se le atribuye esta frase: "Cuando oigo
hablar de cultura quito el seguro de mi Browning".

¿ Tanto lo admiras, que lo citas como si hubiera sido un hombre ilustrado ?

Me parece inverosímil que cites a un vulgar asesino
como si fuera un filósofo a admirar.

Quizás de ahí viene el problema de tu soberbia.

Los nazis siempre creyeron tener la razón en todo.
Por eso asesinaron a tantos.

Es una lástima que tú admires a uno de sus peores prototipos.



Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...

"Alfredo Novoa" wrote in message
news:

A Hermann Goering se le atribuye esta frase: "Cuando oigo hablar de
cultura quito el seguro de mi Browning".

Hola Carlos,

Al margen de lo que haga yo normalmente, que no es la situación de Demián,
sólo decir
que quién quiera adentrarse en el mundo de las tres capas y los objetos de
negocio "perfectamente
diseñados" se asegure de cada paso que de, y si no lo ve claro más vale
que no se meta y acceda
a la BD de una forma directa y clara.

Los requerimientos de seguridad que son necesarios hoy en día en las
aplicaciones obligan a diseñar arquitecturas de este tipo, ya que no es
posible acceder de forma directa a la base de dato, o no se debería.
Y no debemos olvidar que cada día mas existen mas posibilidades en la
implementación de la interfaz de usuario (Web, Windows, PDA, Phone, Office,
etc), y que en muchos casos es necesario implementar varias de estas
posibilidades en función de las necesidades del cliente. En estos casos no
te puedes permitir duplicar la lógica por todas las aplicaciones, sino
factorizar si extraerla a un componente común.

Te puedes confundir al diseñar un objeto de negocio, y te puedes confundir
al diseñar la base de datos, en ambos casos te tocará modificar muchas
cosas. Son niveles de abstracción de un mismo problema. Pero está claro que
si simplemente añadimos un campo nuevo, con un acceso directo a la base de
datos solo tenemos que cambiar la base de datos y la presentación, en la
otra situación tambien tenemos que cambiar los objetos de negocio. Pero
estos objetos son sencillamente niveles de abstracción, que un arquitecto
debe determinar si son o no necesarios en función de las necesidades. Estas
necesidades están cambiando continuamente, cada vez te encuentras con mas
clientes que te dicen que quieren acceder a su aplicación de negocio desde
cualquier sitio con diversidad de dispositivos.

Un Saludo.