sábado, 1 de enero de 2011

La copla del desacople

Cuando empiezas a aprender sobre arquitectura software, descubres muchas reglas que a veces son contradictorias. Cuando ya has aprendido patrones de diseño y patrones de análisis, entonces descubres o te enseñan cosas como que tú tienes que ser muy listo pero tu código muy tonto,  y claro, los patrones de diseño no son precisamente código tonto. ¿En qué quedamos?

Un ejemplo claro que me mantiene entretenido últimamente es la regla de alta cohesión-bajo acoplamiento. Del que se derivan otros como el de OCOR (One Class, One Responsability) o el principio Open-Close (abierto para la extensión, cerrado para la modificación). 
Este principio habla de que los diferentes componentes software han de tener una responsabilidad clara, y deben poder reemplazarse sin que afecte al resto de componentes. Este desacople, que se lleva buscando años, adquiere especial relevancia últimamente, aplicándolo al famosísimo desarrollo en tres capas: vista, negocio y datos.

Lo que se pretende es un desacople total entre estas tres capas. Esto es algo totalmente posible hoy día. Imaginad que los datos los cogemos vía un web service. Entonces, nuestra capa de negocio podría ser totalmente reemplazada, siempre y cuando la nueva, que puede estar en otro servidor, incluso en otro lenguaje de programación, utilice las mismas llamadas al web service (el mismo contrato WSDL). Y lo mismo sucede con la capa vista. Últimamente me ando debatiendo entre si hacer o no una capa vista totalmente desacoplada. Esto es algo sólo viable desde que existe ajax, y desde que el javascript se hizo adulto y el JSON emergió. El JSON es a la capa vista lo que el XML a los web services.

Gracias al JSON, podemos hacer una capa vista totalmente en Javascript, con llamadas asíncronas al servidor para traer cualquier dato que haya que pintar. Las llamadas desde la capa vista siempre devuelven los datos en formato JSON, lo que significa que los controladores del servidor (la C en el MVC que existe en todas las capas vistas bien hechas) podrían ser Java, .NET o PHP por ejemplo. Esto, a priori es genial. Desacoplamiento perfecto. Pero hacer esto es un sobredimensionamiento ¿o no? Supongo que depende de quién lo vaya a programar. Si eres más experto en JQuery que en Java, pues claro, viene bien hacer esto.
Si en tu equipo de desarrollo hay expertos en Javascript/JSON con dominio de JQuery o Prototype, te puedes permitir el lujo de hacer un diseño/arquitectura de baja fidelidad en un lenguaje tipo PHP o Grails, y si el proyecto convence, pasarlo a Java o .Net sin necesidad de tocar ni una línea de la capa vista. Esto es realmente útil, porque lo cierto, y este es otro mandamiento de la arquitectura software, es que para el usuario el interfaz es el sistema, y si ve un interfaz bonito y usable, tienes muchas papeletas para triunfar. Si tu proyecto está pendiente de aprobación o lo tiene que revisar con lupa un equipo de QA, poder prototipar la capa vista sin preocuparse demasiado por la arquitectura de la aplicación es un lujazo, cada día más necesario.  Sí, porque, ¿Cuántas veces habéis hecho unas pantallas para una demo que no ha dado tiempo a terminar, pero tiene que dar el aspecto de que está terminado y funcionando? Yo también muchas veces. Y hacer este tipo de fachadas (pantallas con funcionalidad simulada) es muy más fácil, y da un aspecto más realista cuando todo el interfaz se construye en el cliente (está desacoplado), y sólo tienes que simular las llamadas JSON.

Es así de triste pero es muy cierto: miles de aplicaciones web se venden gracias a su interfaz. Es tan absurdo como elegir un coche sólo porque su carrocería es muy elegante. Con el tiempo se aprende que una arquitectura robusta con un interfaz feo y sobre todo difícil de usar, no vende. Así que si quieres triunfar en este mundillo, más te vale aprender un poco de “capa vista”, y ponerle a tu coche una buena carrocería y un salpicadero impactante.

Todo esto es lo que me hace debatirme entre hacer una capa vista totalmente desacoplada o no. Para la capa de datos ni me lo planteo. Insisto en si me lo estoy planteando para la capa vista es porque la capa vista vende, y, repito, para el usuario/cliente lo es todo. Supongo que acabaré aplicándome la copla ésta del desacople, y lloraré cuando vea trabajar a un desarrollador de .Net, en su maravilloso IDE donde todo está integrado y la programación es casi visual.

Otro inconveniente que observo al llevarme la capa vista a JSON es que, los IDEs no están tan preparados para el Javascript como lo están para el Java, Groovy o .Net. El Javascript ha madurado muy deprisa. Lleva mucho tiempo entre nosotros, pero hasta que no empezó a comer ajax no dio el estirón. Y menudo estirón ha dado. Se le han quedado pequeños todos los IDEs. Espero que esto se resuelva rápido, porque a pesar de la existencia de joyas como Selenium para testar el interfaz y la capa vista en general, sigue habiendo un trecho que recorrer a día de hoy, a principios de 2011.

El caso amigos es que, recapitulando, hay que desacoplar correctamente las clases, los paquetes donde guardas las clases y los componentes software que usan esas clases. Desacoplar la capa vista o la capa datos es también recomendable, pero es un sobreesfuerzo que se ha de sopesar con mucho cuidado. La tecnología JSP y JSTL (dentro del mundo Java) pierden fuerza con estas nuevas tendencias… con lo que me ha costado dominarlas :-)
Sin embargo, no es ni mucho menos, la primera vez que una nueva forma de hacer las cosas triunfa por un solo detalle, a pesar de tener muchos otros en contra. A veces ese único detalle es tan crucial, que merece la pena el sobreesfuerzo. No estoy 100% seguro de que, en el caso que nos ocupa –ese detalle de tener la capa vista totalmente desacoplada– vaya a ser tan crucial. Supongo que es un poco pronto para ello, pero acabaremos haciéndolo. Sobre todo si nuevas tendencias en el desarrollo como CQRS, o el desarrollo orientado a eventos reloaded triunfan próximamente.

Otra vez, se confirma lo que siempre digo, y es que para ser un buen arquitecto software, no basta con saberse las reglas muchas veces contradictorias, sino cuando aplicar una y no su inversa.

3 comentarios:

  1. Buenas,

    Acabo de leer tu post sobre desacople y la verdad es que casi me has leido el pensamiento, desde que estoy empollando jquery he asumido que el único camino válido para las interfaces del los próximos años es trabajar con un framework javascript (ej jquery) y json para mover los datos, supongo que lo que hecho en falta es un framework que estando por encima de query proporcione objetos mucho más completos para diferentes entornos, por ejemplo, he visto plugins de grids, pero nada realmente serio para hacer formularios que jueguen completamente con json.

    Supongo que si una empresa que vende o desarrolla ahora soft en web quiere triunfar, debe hacer primero un framework de maquetación/widgets/navegacion la idea es que el interfaz se cargue una vez, mientras estás en un ámbito y el resto sea trabajo desacoplado, desde que he visto esto, estoy en mis proyectos obligando a currar así y la diferencia es abismal, además la curva de aprendizaje de jquery es bastante baja.

    Saludotes.

    ResponderEliminar
  2. Yo estoy usando ya json con algunos plugins de jquery. JQgrid es el mejor para hacer tablas paginadas/ordenables/selectables/extensibles, etc.

    Pero efectivamente, le falta un poco. Me mola del JSTL poner esto: ${cliente.nombre}
    Si el cliente me lo he traido por json, pintar el nombre implica poner esto: <script>cliente.nombre</script>
    Me parece más elegante el JSTL pero es más depurable/falseable la segunda opción. Además, los diseñadores web quedan desacoplados de la capa de negocio y pueden hacer maquetas 100% funcionales, a la espera de que los programadores hagan la capa de negocio. Aunque se supone que el orden de desarrollo es al revés: datos -> negocio -> vista, en la práctica suele ser así: vista -> datos -> negocio. Sobre todo si hay que hacer demos a clientes.
    Yo aun no he desacoplado del todo y ando mezclando JSTL con JSON. Siendo yo el único desarrollador ahora mismo en mi empresa, me llama más la velocidad de desarrollo que la perfección en una arquitectura 100% desacoplada.

    ResponderEliminar
  3. Pues yo creo que, si el problema es que la capa vista, la de negocio y la de datos, tienen que trabajar asincronamente con el exterior para ser impermeables y sincronicamente en el interior para facilitar la interaccion entre ellas y fluidificar su comunicacion, la solucion es obvia.
    ¡Hay que ponerles a cargo de un director de gestion de recursos que las lleve a las tres por el camino adecuado! Me ofrezco voluntario, a expensas de hablar del sueldo claro.
    Un abrazo Oscar.

    ResponderEliminar