sitio hackeado

[Ubaldo Taladriz]

> En todo caso el esquema de modelo de capas es el mas adecuado para la 
> construccion de sistemas por el concepto de encapsular la logica en el 
> cliente.

La lógica en el cliente en un modelo de capas¿? Plop.

Será por eso que hoy en día estamos hablando de SOA.
 
Definitivamente la lógica no está en el cliente y ojo que la lógica no
son las validaciones de los campos de entrada. Esto es así áun cuando
hoy están de vuelta los clientes con mayores capacidades, ocupando
modelos AJAX o productos como Flex de macromedia.

El otro comentario que a mi modo de ver tampoco aplica,  fue una
referencia a extreme programming "Y no es una decision fija, _ahora_ se
necesita en MySQL si despues alguien mas lo necesita en otro tipo de
sistema se modifica"

http://en.wikipedia.org/wiki/Extreme_Programming
"

Que es algo tan vago como decir, bueno ahora se necesita como aplicación
web, mañana como web services integrados a otras compañías y ahí veremos
como lo hacemos.

¿Qué tiene que ver eso con Extreme programming?
Supongo que tiene ver con el valor de la simplicidad, que al parecer al
traducirlo en Chileno suena como el valor de la improvisación del
maestro chasquilla o puede ser que tenga ver con el principio de
"aceptar los cambios" el cual hace referencia  a cambios funcionales.

En mi opinión el tratar de mantener la simplicidad del sistema, que se
resume en la vieja regla KISS (Keep it simple stupid), que es bastante
anterior a XP, no abarca  y por lo tanto no se hace cargo, de
requerimientos no funcionales tales como la flexibilidad, la
mantenibilidad y la portabilidad. Estas "bilidades"  son resueltas por
la arquitectura del sistema,  y no por un valor, que este caso más bien
suena a una apuesta o a una decisión de negocio, ahora en el corto plazo
se necesita en MySQL, hagamos caja, después vemos si sale algo más.

Mi último punto tiene que ver con el origen de la discusión. Mientras
menos dependo de la BD, pierdo en eficiencia, pero gano en portabilidad.
Es teniendo en cuenta esto que discrepo de Alvaro. La pega de la BD son
los datos, y por lo tanto habitualmente lo que dejo a cargo de la bd,
son movimientos masivos de datos. El resto, todo a la capa intermedia.
Es decir, triggers, stored procedures, son bienvenidos para resolver la
problemática de datos, nada más

Saludos




-- 
Ubaldo Taladriz
EXE Ingeniería 
--------------------
http://www.exe.cl
Exe Ingeniería & Software Ltda.
Europa 1935 Providencia - Santiago
Código Postal : 750-0568
Tel  (56-2) 2049366 Fax  (56-2) 2040897 
counter.linux.org #274593