Separación en capas

Existen lenguajes con los que resulta natural la programación en capas y otros con los cuales parecería que no es necesario. En apariencia, si desarrollamos en C#.NET, debemos separar en capas puesto que el lenguaje nos “obliga a programar bien”. En cambio si hacemos una aplicación en ASP, entonces está “bien” poner “todo junto” ya que es un lenguaje de scripting en donde “todo vale”.

Nada de lo anterior es cierto. Es muy fácil programar en C#.NET sin separar en capas, de hecho, he visto muchos desarrollos en los que casi todo el código estaba concentrado en el evento Page_Load. También se puede programar en ASP separando el código en capas.

La separación en capas es, en principio, algo teórico, formal. Se diseña en capas. Podemos desarrollar una aplicación en C# con capa de presentación, de negocios y de acceso a datos en una sola DLL y, aún así, las capas seguirán existiendo. También se puede separar en capas una aplicación íntegramente desarrollada en ASP.

Son muchos los beneficios que obtenemos con esta práctica y, de entre ellos, podemos citar:

• Clara distribución de las responsabilidades.
• Nos permite tener múltiples presentaciones para una misma aplicación (ASPX, WebService, Win32)
• Podemos cambiar de repositorio de datos sin impacto en el resto de la aplicación.
• Es más fácil trabajar en equipo con otros desarrolladores y hasta armar equipos de desarrolladores para cada capa.
• El código se vuelve mucho más claro y fácil de mantener.

En los próximos artículos vamos a hablar específicamente de cada capa. También vamos a ir mostrando cómo se puede implementar en ASP tradicional.Esto lo haremos por dos razones fundamentales. En primer lugar, no existen muchos ejemplos de cómo separar en capas con ASP tradicional en Internet. Además intento mostrar lo importante que es diseñar en capas aún cuando la implementación no separe estrictamente el código en DLLs.

Diseño independiente de la plataforma

El desarrollo de aplicaciones web tiene varias etapas que, por lo general, son estas:

• Enumeración de necesidades
• Creación de especificaciones
• Análisis
• Diseño
• Desarrollo
• Implementación
• Mantenimiento

Cada una de estas etapas debe ser independiente de las demás. Esto significa que no debemos permitir que nuestro conocimiento o experiencia acerca de las etapas siguientes interfieran en nuestro criterio sobre la etapa actual.

Particularmente me interesa hacer un comentario sobre la etapa de Diseño debido a que esta y la de Desarrollo suelen ser cumplidas por las mismas personas o, mejor dicho, parte del equipo de desarrollo suele participar en la etapa de Diseño.
Muchas veces he visto, a miembros del equipo, invalidar parte de un diseño porque sería más o menos complicado de desarrollar. Este es uno de los errores más comunes en el desarrollo de aplicaciones en general. Un diseño bien hecho es muy importante como para que sólo quede en una frase de compromiso.

La etapa de Diseño es independiente de la plataforma sobre la que se va a desarrollar. No podemos pensar en que si fuera en ASP entonces estaría bien, pero si fuera en Flash entonces el diseño estaría mal. Si el diseño está bien hecho, seguirá estando bien cualquiera sea la plataforma que se decida utilizar el la etapa de Desarrollo.

Simple es mejor

Cuando veo un desarrollo de esos en los que una página ASP usa un objeto SOAP para conectar a un WebService .NET, el cual, vía DCOM se comunica con un servidor que, a través de un motor de persistencia logra actualizar un contador de visitas, lo primero que pienso es: "El programador que hizo esto ha leído mucho".
Lo que verdaderamente despierta mi admiración son aquellas soluciones que resuelven problemas de forma tan sencilla que, luego de implementadas, hacen que todos digan: "era muy fácil".

La regla número uno de los desarrolladores debe ser KISS: "Keep it simple, stupid" (mantenlo simple, estúpido).
Si un problema admite más de una solución, entonces seguramente, la más sencilla será la mejor y la que tendrá menos problemas en el futuro. Por otra parte, cuanto más sencillo se mantenga un desarrollo, más fácil será para un compañero continuarlo.

En una ocación, mi jefe me pidió que resolviera el problema de una página ASP que daba error de "Time Out" debido a que ejecutaba un proceso que habitualmente demoraba mucho tiempo. Luego de analizarlo, llamé a mi jefe y le mostré la solución: la página ya no ejecutaba más ese proceso. No sé si fue mi mejor trabajo, pero seguro que estuvo libre de "bugs".