Arquitecturas de niveles independientes
Desde hace tiempo he venido trabajando con modelos de software cada vez más segmentados, y esto tiene ventaja de facilitar el mantenimiento de nuestros desarrollos. Con esta segmentación viene también un aumento de complejidad, y en ocasiones surgen errores que nos impiden trazar o si quiera ejecutar nuestra aplicación. Ahí es cuando recuerdo las primeras clases de programación (cuestiones que muchas veces solemos obviar), como la de ESCRIBIR en papel un algoritmo, DISEÑAR en papel un diagrama de flujo.
Ahora que los sistemas se vuelven más complejos, en funciones como en estructura, desarrollar esos algoritmos se vuelve crucial, pero ya no es suficiente solo realizarlos como antes, ahora hay que adaptarlos para que sean efectivos. ¿Bajo qué esquema?.
El más acertado sería: basar estos algoritmos en función de las actividades que se espera poder realizar con el sistema. Ejemplificando...
Podemos tener un sistema de 3 capas donde la primera es la de acceso a la base de datos, la segunda es la que nos permite implementar las reglas del negocio y la tercera es la de la interfaz. Así, en la primera programamos nuestras clases que se dedican a extraer datos y recuperarlos de la base de datos sin preocuparnos (casi) de validarlos, ya que estos serían validados en la capa siguiente. De esta forma exponemos métodos que reciben parámetros y devuelven resultados, encapsulando la lógica de cómo se almacenan y cómo se recuperan. Para la segunda capa consume estas clases para el almacenamiento y recuperación de datos, pero en esta capa se validan los datos antes de ser almacenados, y se estructuran antes de ser enviados a la interfaz, ya que es normal que se utilicen en una estructura en particular para formularios, en otra para listados y consultas, y una más para reporteo. Nuevamente, esta capa produciría clases que exhiben métodos para enviar y recibir información hacia la interfaz. Finalmente, la interfaz sería una capa combinada (la lógica tras la parte visual y la parte visual misma) que consume los métodos de la capa de negocios, y donde se realizan las validaciones más simples de los datos; de esta manera, si se requiere un cambio en el diseño de la interfaz que no implique agregar más lógica de negocios o de datos, solo se modifica la capa de interfaz, lo mismo para el cambio en la lógica de negocio y de datos, siempre que no se requiera un cambio en las tres capas. Otro ejemplo de esta arquitectura es MVC, la cual se define como Modelo-Vista-Controlador, donde el Modelo contiene todo lo necesario para definir la estructura de los datos, así como también la lógica de su acceso, almacenamiento y recuperación, el Controlador se encarga de la lógica de negocios y el trabajo con los datos por medio del modelo, mientras que la Vista es la parte de la interfaz.
En determinado momento, entre más capas seamos capaces de manejar en un proyecto, más fácil será su mantenimiento, más organizado su crecimiento aunque implique más trabajo, aparentemente. ¿Por qué? porque tendrás bien identificado dónde realizar determinados cambios, será más sencillo aislar bugs, detectar errores y no tendrás que nadar por todo el proyecto para rastrearlo.
Ahora que los sistemas se vuelven más complejos, en funciones como en estructura, desarrollar esos algoritmos se vuelve crucial, pero ya no es suficiente solo realizarlos como antes, ahora hay que adaptarlos para que sean efectivos. ¿Bajo qué esquema?.
El más acertado sería: basar estos algoritmos en función de las actividades que se espera poder realizar con el sistema. Ejemplificando...
Podemos tener un sistema de 3 capas donde la primera es la de acceso a la base de datos, la segunda es la que nos permite implementar las reglas del negocio y la tercera es la de la interfaz. Así, en la primera programamos nuestras clases que se dedican a extraer datos y recuperarlos de la base de datos sin preocuparnos (casi) de validarlos, ya que estos serían validados en la capa siguiente. De esta forma exponemos métodos que reciben parámetros y devuelven resultados, encapsulando la lógica de cómo se almacenan y cómo se recuperan. Para la segunda capa consume estas clases para el almacenamiento y recuperación de datos, pero en esta capa se validan los datos antes de ser almacenados, y se estructuran antes de ser enviados a la interfaz, ya que es normal que se utilicen en una estructura en particular para formularios, en otra para listados y consultas, y una más para reporteo. Nuevamente, esta capa produciría clases que exhiben métodos para enviar y recibir información hacia la interfaz. Finalmente, la interfaz sería una capa combinada (la lógica tras la parte visual y la parte visual misma) que consume los métodos de la capa de negocios, y donde se realizan las validaciones más simples de los datos; de esta manera, si se requiere un cambio en el diseño de la interfaz que no implique agregar más lógica de negocios o de datos, solo se modifica la capa de interfaz, lo mismo para el cambio en la lógica de negocio y de datos, siempre que no se requiera un cambio en las tres capas. Otro ejemplo de esta arquitectura es MVC, la cual se define como Modelo-Vista-Controlador, donde el Modelo contiene todo lo necesario para definir la estructura de los datos, así como también la lógica de su acceso, almacenamiento y recuperación, el Controlador se encarga de la lógica de negocios y el trabajo con los datos por medio del modelo, mientras que la Vista es la parte de la interfaz.
En determinado momento, entre más capas seamos capaces de manejar en un proyecto, más fácil será su mantenimiento, más organizado su crecimiento aunque implique más trabajo, aparentemente. ¿Por qué? porque tendrás bien identificado dónde realizar determinados cambios, será más sencillo aislar bugs, detectar errores y no tendrás que nadar por todo el proyecto para rastrearlo.
Comentarios
Publicar un comentario