Ayuda modelo de tres capas...

Hola Juan,

nunca nadie ha dicho tantas cosas ciertas en un mensaje.
Si lees mi primera respuesta a Alfredo en este hilo podrás ver como
anticipaba el final, pero bueno, como has indicado ya se han producido
muchos hilos en este y otros foros, en donde el subject era uno de los
siguientes:
- tres capas
- arquitectura
- modelo
Y que tras la participación de Alfredo han terminado igual que este, con
muchos mensajes y sin nada claro para la persona que buscaba una simple
solución a su problema.

Creo que invertiré mi poco tiempo libre en seguir ayudando a personas como
Demian, y no perder el tiempo en discusiones contra la pared.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Juan T. Llibre" escribió en el mensaje
news:

re:

No has entendido lo que quería decir.

Alfredo,
( y que me excuse Demian por este desvío del tema... )

Con todo respeto, pues creo que eres un hombre inteligente e instruído,
aunque los mas inteligentes e instruídos son, precisamente, los que
revisan su proceder cuando encuentran una crítica justificada,
creo que tienes que poner los piés un poco mas en la tierra.

A mí me ha curioseado tanto tu posición de "alto nivel académico",
que he hecho algo de investigación sobre tu perfil como participante
de los foros de usenet, incluyendo los de Microsoft.

Lo que he encontrado me ha dejado boquiabierto.

En uno de los hilos en que participaste, de un total de 572 mensajes
escribiste 123 de los mismos, indicando que tienes una persistencia
increíble para la polémica.

En ese hilo, varios participantes se quejaron de tu insistencia en que
solo tú tienes las llaves del conocimiento, y hasta se burlaron de tus
argumentos a ese respecto.

Mas increíble aún, tienes ese problema en ambos idiomas en que escribes,
pues tanto en español como en inglés, la misma queja es externada :
que te mantienes en un nivel de aire rarificado, de discusión de "alto
nivel",
sin que tus "contribuciones" ayuden a nadie a obtener una respuesta
adecuada
a las preguntas que se te hacen, proveyendo, como contraparte inútil, un
sin fín
de alegadas superioridades de tus formas de pensar.

Como te indicó el último interlocutor del hilo kilométrico referido:
"Use your alleged vast genius to produce source-code evidence instead of
just hot air."

"Usa tu alegado vasto genio para producir evidencia basada
en código fuente, en vez de estar soplando aire caliente."

Y es que te has manifestado como experto en todo,
y eso cansa, además de ser indicativo de un serio caso de pedantería.

Eso que escribo te lo han señalado mas de
una docena de participantes en los pocos hilos que revisé.

Tu respuesta, por lo general, ha sido el reafirmar lo que dices, múltiples
veces,
lo que realmente no constituye la base ideal para tener un diálogo útil.

Adoleces de 3 defectos, primordialmente.

1. Siempre quieres tener la última palabra, aún sin tener razón.
2. No sabes cuando es tiempo de decir: "es suficiente".
3. Tiendes a establecer bases de diálogo donde la alegada
superioridad intelectual tuya tiene que ser aceptada.

Creo que sería de mucho mas utilidad para las comunidades
en que participas si admitieras que, de vez en cuando, alguna
otra persona que no sea tú tiene razón en algún argumento,
y que dejes la pedantería de insistir en que tienes razón todo el tiempo.

Espero que estos comentarios te hagan reflexionar sobre tus actitudes,
evitando de esa manera los, ya frecuentes, choques con interlocutores
de las comunidades virtuales por tu insistencia en estar correcto el 100%
del tiempo en *todos* los argumentos en que participas.

Ya otros te han dicho lo mismo
...y has seguido "tan campante como Johnnie Walker"

La alternativa que yo tendría, de tu insistir en los mismos métodos de
argumento que has exhibido historícamente, sería el citar nombres,
fechas y citas de los múltiples argumentos que has tenido en usenet
y los grupos de discusión de Microsoft, que prueban, mas allá de
cualquier alegato tuyo, la veracidad de lo que he escrito hoy aquí.

Espero que esta vez entiendas mejor lo que se te está exponiendo.
Un poco de reflexión antes de contestar, te valdría de mucho.




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:

On Fri, 1 Jul 2005 10:14:16 -0400, "Juan T. Llibre"
wrote:

Alfredo,

no crees que esta cita tuya :

000
Este es el error fundamental de muchos de vosotros los amigos de las
siglas que empiezan por M, que os creeis que por haber hecho un
cursillo de Microsoft ya os lo sabeis todo y no necesitais leer nada
más, especialmente textos de nivel académico.
000

es algo injusta ?

No lo creo.

Particularmente, en el caso de aquellos que sí han leído los tan
cacareados
"textos de nivel académico" a que haces referencia, y tienen buena
formación
académica, habiendo logrado un grado o posgrados en Ingeniería de
Sistemas,
por ejemplo, y *además* tienen las certificaciones/siglas que comienzan
con M,
que aparentemente deseas descalificar.

Es que no va por ellos, evidentemente. Va por los otros, por los que
*solo* tienen certificaciones de fabricantes, no tienen ninguna
preparación científica y se creen los reyes del mambo.

No has entendido lo que quería decir.


Saludos

Hola Carlos,

en parte tienes razón y mucha razón, he visto proyectos muy retrasados por
intentar aplicar alguna metodología, pero el problema está en querer
utilizar algo sin tener las bases para aplicarlo como has indicado antes.

De todas formas te comento que para implementar los objetos de negocio no es
necesario aplicar UML, si tienes las ideas claras de lo que tienes que hacer
puedes hacerlo sin problemas, aunque no quedará mucha documentación para
volver a retomar el proyecto dentro de x tiempo. En el caso de Demian puede
que no sea un mal mayor puesto que el proyecto lo hará el sólo.

Lo importante es ir aprendiendo poco a poco como mejorar en todos los
aspectos de un proyecto, para así hacer cada día mejor el trabajo. Y sin
duda en el momento en que se aprenden estas metodologías, las adaptas a tu
manera, y las aplicas sin problemas, pero como tu dices a la manera de cada
uno.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Carlos García-Carazo" <sharpmanArrobaqueterroba_terra.es> escribió en el
mensaje news:

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.

Hola Demian,

yo por ejemplo he llegado a utilizar la herramienta CodeSmith, con
modificaciones sobre las plantillas que vienen con el producto, para generar
todas las clases de acceso a datos. En el momento que creas una plantilla te
sirve para muchos proyectos, pero si no tienes tiempo para crear la
plantilla inicial puedes perder un tiempo muy preciado.

Si lo que has implementado te funciona y crees que no te dará problema, y
sobre todo no tienes mucho tiempo para desarrollar, lo mejor es que te
preocupes del resto de la aplicación (pantallas y lógica de negocio
necesaria)

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Demian" escribió en el mensaje
news:

Yo mismo he implementado la clase y digamos que me funciona bien con
comandos
simples de diversos tipos, es decir en base a la llave primaria de la
tabla(la cual obtiene del esquema de la base de datos) y obvio con los
valores que el objeto que utiliza dicha clase tiene establecidos,
construye
los comandos mas comunes de seleccion, eliminacion, insercion y
actualizacion

Crees tu que esto sea correcto? bueno aunque en general entiendo tu idea
de
tener los procedimiento almacenados y la razon por la cual los usas pero
en
parte como soy el unico programador, esto me implica coste de tiempo en
mis
desarrollos pero temo que en un futuro el hacer dependientes mis clases me
pueda dar algun problema... Saludos y muchas gracias



"Miguel Angel Campos" wrote:

Hola Demian,

Según cuentas lo tienes bien planteado, aunque yo utilizaría
procedimientos
almacenados en lugar de sentencias SQL, pero todo depende de la siguiente
pregunta que te realizo a continuación.
Has comentado algo de reflection, ¿lo estas haciendo con una libreria
específica de terceros, o has implementado algo tu mismo? No se si estas
utilizando un O/R Mapping u otra cosa.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Demian" escribió en el mensaje
news:
> De hecho, en mis clases por el momento lo hago como me lo recomiendas,
> es
> decir, mi capa logica del negocio tiene los comandos Sql que se
> ejecutaran
> en
> la capa de datos, y utilizo componentes basados en el ambito reflection
> que
> analizan mis objetos para establecer sus propiedades, o bien para leer
> desde
> ellas y construir comandos, entiendo que esto puede no ser muy
> eficiente
> pero en general me minimiza mucho el tiempo de desarrollo, lo malo es
> que
> mis
> clases se hacen un poco dependientes de esas clases que construyen los
> comandos
>
> Crees tu que esto esta esta bien planteado? Saludos y gracias de
> antemano
> por tu respuesta...
>
> "Miguel Angel Campos" wrote:
>
>> Hola Demian,
>>
>> Yo te recomiendo desarrollar una serie de componentes que forman la
>> lógica
>> de negocio, que expondrían toda la funcionalidad que necesites (crear
>> Pedido, obtener Pedido, etc)
>> Dentro de estos componentes utilizaría procedimientos almacenados, es
>> lo
>> recomendado, pero podrías utilizar tambien sentencias SQL, cuidado con
>> la
>> injección de codigo.
>> Y consumiría estos componentes desde la interfaz de usuario, que
>> podría
>> ser
>> Web, Windows, VSTO, etc.
>> ¿Donde situar esos componentes intermedios? por ahora tienes que tomar
>> la
>> decisión en función de las necesidades que tengas para el proyecto
>> (COM+,
>> WebService, Remoting, etc), en un futuro tendras Indigo que permitirá
>> cambiar de uno a otro mediante configuración.
>>
>> Un Saludo,
>>
>> Miguel Angel Campos
>> MCAD.NET
>>
>> "Demian" escribió en el mensaje
>> news:
>> > Hola, tengo una duda en cuanto al modelo de tres capas..
>> >
>> > En general no se donde deben escribirse los comando sql de mi
>> > aplicacion,
>> > no
>> > se si es parte de la capa de datos o bien es parte de la capa
>> > logica...
>> >
>> > Entiendo que puedo programar procedimientos almacenados para
>> > recuperar
>> > la
>> > información y despues mediante los proveedores de datos de .net
>> > ejecutarlos,
>> > con lo cual obviamente mis sentecnias sql estarian en el lado de la
>> > capa
>> > de
>> > datos y obtendría una aplicacion mas migrable, sin embargo, todas
>> > mis
>> > aplicaciones estarían en un servidor y esto podria afectar el
>> > rendimiento
>> > del
>> > mismo.
>> >
>> > Otra opcion es tener una funcion de datos para cada accion que desee
>> > realizar en el servidor, por ejemplo un metodo InsertarPedido, otro
>> > InsertarFactura, y otro mas llamado InsertarAmortizaciones. Esto
>> > estaria
>> > bien, sin embargo alarga el tiempo de desarrollo de aplicaciones.
>> >
>> > La opcion que estopy tomando es tener funciones de datos generales,
>> > por
>> > ejemplo
>> > InsertarRegistro o bien InsertarRegistros, a las cuales les paso
>> > comandos
>> > sql o bien una lista de parametros que la funcion pueda reconocer y
>> > con
>> > ello
>> > construior un comando que ejecutaria posteriormente. El asunto con
>> > esto
>> > que
>> > mi applicacion no es tan migrable y apartentemente mezcla un poco la
>> > logica
>> > de negocio con la capa de datos, sin embargo me gustaría saber si lo
>> > que
>> > estoy haciendo es conveniente y de no serlo cuales son las razones
>> > por
>> > las
>> > cuales no debo programar de esta forma.
>> >
>> >
>>
>>
>>

On Fri, 1 Jul 2005 12:11:16 -0400, "Juan T. Llibre"
wrote:

En uno de los hilos en que participaste, de un total de 572 mensajes
escribiste 123 de los mismos, indicando que tienes una persistencia
increíble para la polémica.

Eso no quiere decir nada, por que seguro que habría otra gente que
participó en tantos o más mensajes que yo. Pero claro, eso no lo
dices.

En ese hilo, varios participantes se quejaron de tu insistencia en que
solo tú tienes las llaves del conocimiento, y hasta se burlaron de tus
argumentos a ese respecto.

A mi me parece muy mezquino hacer ese tipo de alusiones sobre todo sin
dar referencias, aunque eso tampoco quiere decir nada, por que es lo
que suele hacer muchísima gente en todas las discusiones. Todos se
quejan de la insistencia de los demás y no ven que ellos mismos son
tanto o más insistentes.

Además he filtrado unas cuantas personas que no han sabido comportarse
con un mínimo de dignidad y coherencia, y a estos les he dejado decir
la última palabra y todas las que quieran. Como por ejemplo a Tristán
y a Morcillo de estos foros. Como sigas con esta actitud este es el
último mensaje que te dirijo.

Mas increíble aún, tienes ese problema en ambos idiomas en que escribes,
pues tanto en español como en inglés, la misma queja es externada :
que te mantienes en un nivel de aire rarificado, de discusión de "alto nivel",

A saber que has leido. He participado en cientos de discusiones en las
que nadie me ha dicho nada parecido, incluso algunas veces me han
dicho que debería de ser más preciso, cuidadoso y riguroso, y estoy
intentando seguir el consejo :)

Aunque si que es cierto que eso me lo suele decir la gente de muy bajo
de nivel de preparación que se queda sin argumentos y recurre a este
tipo de juego mezquino y despreciable en el que estás cayendo.
Vergüenza debería de darte.

sin que tus "contribuciones" ayuden a nadie a obtener una respuesta adecuada
a las preguntas que se te hacen, proveyendo, como contraparte inútil, un sin fín
de alegadas superioridades de tus formas de pensar.

Eso será tu opinión. He recibido bastantes mensajes de apoyo
animándome a continuar con el buen trabajo, tanto en inglés como en
español, y también de gente agradecida que me ha dicho que ha
aprendido cosas útiles y ha encontrado temas en los que pensar leyendo
las discusiones.

Además en muchas de las discusiones en inglés en las que he
participado había otras muchas personas que defendían exactamente las
mismas ideas que yo y eran tanto o más insistentes.

Por suerte los paises desarrollados del norte de Europa las cosas no
están tan mal como aquí, y hay mucha gente con un buen nivel de
preparación, aunque por supuesto siguen siendo minoría.

Desgraciadamente lo del Tercer Mundo lo dicen por algo.

Como te indicó el último interlocutor del hilo kilométrico referido:
"Use your alleged vast genius to produce source-code evidence instead of just hot air."

"Usa tu alegado vasto genio para producir evidencia basada
en código fuente, en vez de estar soplando aire caliente."

Eso es una idiotez, yo me paso el dia creando código fuente, pero no
voy a hacer el trabajo de los demás en los grupos de noticias, sería
lo último que me faltaba.

Eso que escribo te lo han señalado mas de
una docena de participantes en los pocos hilos que revisé.

Ya, eso lo explica todo. Te has leido un par de hilos y ya crees que
te lo sabes todo sobre mi.

Tu respuesta, por lo general, ha sido el reafirmar lo que dices, múltiples veces,
lo que realmente no constituye la base ideal para tener un diálogo útil.

¿Ah, no?

Según tú tendría que decir cada vez una cosa diferente y
contradictoria como algunas personas que andan por aquí.

Esto va de mal en peor y confirma la muy mala impresión que me
causaste cuando discutíamos sobre como aprender a programar.

Creo que sería de mucho mas utilidad para las comunidades
en que participas si admitieras que, de vez en cuando, alguna
otra persona que no sea tú tiene razón en algún argumento,
y que dejes la pedantería de insistir en que tienes razón todo el tiempo.

He admitido muchas veces argumentos de otros, lo que no voy a hacer es
admitir una tontería por que tu lo digas.

Además mucha más insistencia tienen los que defienden las tonterías
que intento combatir. Por cada mensaje en defensa de los principios
científicos de la profesión, hay literalmente miles que hacen todo lo
contrario y alimentan la espiral del borreguismo que tú quieres
fomentar.

La alternativa que yo tendría, de tu insistir en los mismos métodos de
argumento que has exhibido historícamente, sería el citar nombres,
fechas y citas de los múltiples argumentos que has tenido en usenet
y los grupos de discusión de Microsoft, que prueban, mas allá de
cualquier alegato tuyo, la veracidad de lo que he escrito hoy aquí.

No hace falta, admito abiertamente haber defendido siempre las mismas
ideas básicas que vienen en TODOS los libros de texto de sistemas de
bases de datos y que son generalmente aceptadas por la comunidad
científica.

No veo nada malo en ello y lo seguiré haciendo mientras pueda y me
queden ganas.

Es llamativa la irritación que produce la palabra "ciencia" en muchos
programadores.

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

Hola, sólo una matización:

De todas formas te comento que para implementar los objetos de negocio no es
necesario aplicar UML, si tienes las ideas claras de lo que tienes que hacer
puedes hacerlo sin problemas, aunque no quedará mucha documentación para
volver a retomar el proyecto dentro de x tiempo. En el caso de Demian puede
que no sea un mal mayor puesto que el proyecto lo hará el sólo.

Bueno, no me refería a UML sólo como lenguaje de diagramas y artefactos sin más,
aunque es verdad que no queriendo entrar en detalle he sido algo ambiguo.

En lo que yo estaba pensando al poner UML es en la gran cantidad de conceptos
que se plasman a través de este lenguaje, conceptos muy relacionados con el
análisis y diseño OO como: Actor, Contrato, Responsabilidad, Colaboración, Agregación,
Composición, Estereotipo, etc...

No conocerlos bién, tal y como se entienden en el mundo del OOAD, puede llevar a
que cuando estés diseñando un objeto de negocio "puro" realmente no lo estés haciendo
tan reutilizable como creías, a un nivel conceptual, y puede pasar que cuando pretendas
usar ese objeto en un entorno de negocio alterado descubras que no estaba bién diseñado
y te tocará rediseñarlo. Si bién es cierto que esto no tiene por qué llevar más tiempo que preverlo
correctamente (diseñándolos "bién" todos yo diría que tardarías más que cambiando uno concreto),
y al errar en el diseño ya estás perdiendo parte de la proclamada reusabilidad de los objetos de negocio,
y por tanto no debería sacrificarse "por sistema" las ventajas de un acceso directo a BD.

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.

Saludos