En estos días escribí en un foro muy conocido por programadores en facebook sobre lo muy mal que es escribir códigos al mejor estilo de un plato de spaguetti. No solo es totalmente antiprofesional, sino que ademas causa malestar a largo plazo para los que les toque mantener ese programa (inclusive para el que lo programó).
Usualmente la falta de una buena estructura es la causa más común para generar macarronicidios, sin embargo lo más importante es entender las reglas del negocio. Si no sabemos exactamente qué desea el cliente mucho menos vamos a saber por donde siquiera empezar. Allí está el dilema, hay que hacer aunque sea un pequeño análisis y luego a partir de alli descomponer el proyecto en partes más manejables.
Una sugerencia que les doy es trabajar por capas, es decir, descomponer el proyecto o componentes (una vez realizado el análisis) en capas muy específicas que harán tareas específicas, por ejemplo, un grupo de componentes se encargará de gestionar todo lo que hay en la base de datos, otro grupo podría ser el que gestione todo lo que son entradas y salidas del usuario, etc.
Veamos un ejemplo de programación por capas:
Imaginemos que necesitamos una pantalla para incluir el registro de un cliente, entonces hay que investigar qué datos se requieren en el registro (nada de inventar campos que no se van a usar, solo lo justo y necesario), qué debe hacer el sistema con esos datos (guardarlos en una base de datos, mandar un correo, etc.) y por ende qué información debe enviarle de vuelta el sistema al usuario (incluyendo validaciones, mensajes, etc.) con esa información podemos comenzar a descomponer nuestro proyecto por capas.
La primera capa evidente es la que llamaremos el modelo, es decir, la data que vamos a manejar y el modelo usualmente está relacionado a un objeto de la vida real por donde se debe realizar la operación específica, por ejemplo, en este caso el cliente. Por lo tanto ya tenemos definido nuestro primer objeto en la capa modelo y lo llamaremos cliente.
Esta capa debe tener la información del cliente en si, por ejemplo, identificación, nombre, dirección, etc. Sólo la información que es solicitada por la empresa que nos contrata, nada de inventar sofisticaciones, acuérdense, lo justo y necesario. (sobre todo para poder levantar un prototipo).
Si hay una información adicional a parte del cliente puede ser otro objeto pero también debe ir en la capa de modelo.
Una vez tenemos definido el modelo, es casi seguro que estos van a estar relacionados uno a uno con tablas en la base de datos (incluyendo cada campo como una columna en la base de datos).
Nuestra segunda capa es la de el manejo de los datos para cada uno de los modelos, esos objetos (en nuestro ejemplo deben ser guardados en la base de datos y enviados a un correo), por lo tanto se requiere de crear objetos que inserten, actualicen, borren, etc. la información de esos objetos en la base de datos, en el argot tecnológico este tipo de capa se le llama Data Access Object (DAO). Al separar los objetos que gestionan la información en la base de datos de los modelos les permitirá en un futuro cambiar la tecnología, por ejemplo para .NET o Java podrían utilizar una librería que se llama hibernate para manejar la gestión de las operaciones en la base de datos y si en el futuro deben cambiar de libreria solo tienen que cambiar esa capa y no el resto de la aplicación (ya ven la ventaja?).
Ahora nuestra siguiente capa, es la que manejará las reglas del negocio específicas, es decir, debe calcular algo entre campos?, validar algo?, etc. Esta es nuestra capa de los servicios (en algunos casos le llaman Business Objects, otros le llaman Services Objects) pero estos conversan con los DAOs para manipular información específica entre los datos que entran en el sistema y la información de como debe ser manejada. En algunas ocasiones cuando no hay reglas de negocios específicas se puede acceder directamente a los DAOs sin tener una capa de servicios, pero yo recomiendo no saltarse esta capa por las razones expuestas arriba, puedo cambiar de base de datos, controladores de base de datos, tecnología y solo debería cambiar los DAOs mas no asi los servicios.
Y ahora nuestra capa de control, esta capa es la que agrupará todos los objetos que deben gestionar nuestro flujo de navegación del sistema, es decir, dependiendo de lo que nos devuelva los services entonces debe ir a una página específica o enviar información de vuelta a la interface gráfica. Por ejemplo, si el usuario se registra como cliente premiun debe ir a una página (previa inserción en la base de datos por el DAO y validación por el service, etc.) y si es otro tipo de usuario debe enviar un correo. Bueno, el asunto es que esta capa controla el flujo de a donde debe ir y que debe retornar al usuario.
Por último tenemos la capa de la vista, esta capa es la que mostrará la información al usuario como resultado de alguna operación o cambios en el sistema, esta capa usualmente está relacionada intimamente con el lenguaje a utilizar para el despliegue de la información en el sistema. Si es una página web esta capa gestiona la información de cómo debe enviarse y cómo debe visualizarse (ya sean botones, mensajes, cajas de dialogo, etc.)
En algunas aplicaciones web mas complejas se agrega una capa intermedia entre la vista y los controladores, esta capa es la de los web services que como están de moda se usan los restful que son los más estándares para convesar entre el lenguaje que se utiliza en la capa vista y la capa de control.
En resumen se tienen las siguientes capas:
1. Modelo.
2. Data Access Object
3. Services (opcional)
4. Controllers
5. Web Services (opcional)
6. Vista o Interface de usuario.
Al tener separada nuestra aplicacion de esta forma es seguro que si el día de mañana hay que cambiar algo no hay que hacerlo en todo el sistema y solo se hace en pocos componentes y tu aplicación es mucho más facil de entender.
Saludos!
Usualmente la falta de una buena estructura es la causa más común para generar macarronicidios, sin embargo lo más importante es entender las reglas del negocio. Si no sabemos exactamente qué desea el cliente mucho menos vamos a saber por donde siquiera empezar. Allí está el dilema, hay que hacer aunque sea un pequeño análisis y luego a partir de alli descomponer el proyecto en partes más manejables.
Una sugerencia que les doy es trabajar por capas, es decir, descomponer el proyecto o componentes (una vez realizado el análisis) en capas muy específicas que harán tareas específicas, por ejemplo, un grupo de componentes se encargará de gestionar todo lo que hay en la base de datos, otro grupo podría ser el que gestione todo lo que son entradas y salidas del usuario, etc.
Veamos un ejemplo de programación por capas:
Imaginemos que necesitamos una pantalla para incluir el registro de un cliente, entonces hay que investigar qué datos se requieren en el registro (nada de inventar campos que no se van a usar, solo lo justo y necesario), qué debe hacer el sistema con esos datos (guardarlos en una base de datos, mandar un correo, etc.) y por ende qué información debe enviarle de vuelta el sistema al usuario (incluyendo validaciones, mensajes, etc.) con esa información podemos comenzar a descomponer nuestro proyecto por capas.
La primera capa evidente es la que llamaremos el modelo, es decir, la data que vamos a manejar y el modelo usualmente está relacionado a un objeto de la vida real por donde se debe realizar la operación específica, por ejemplo, en este caso el cliente. Por lo tanto ya tenemos definido nuestro primer objeto en la capa modelo y lo llamaremos cliente.
Esta capa debe tener la información del cliente en si, por ejemplo, identificación, nombre, dirección, etc. Sólo la información que es solicitada por la empresa que nos contrata, nada de inventar sofisticaciones, acuérdense, lo justo y necesario. (sobre todo para poder levantar un prototipo).
Si hay una información adicional a parte del cliente puede ser otro objeto pero también debe ir en la capa de modelo.
Una vez tenemos definido el modelo, es casi seguro que estos van a estar relacionados uno a uno con tablas en la base de datos (incluyendo cada campo como una columna en la base de datos).
Nuestra segunda capa es la de el manejo de los datos para cada uno de los modelos, esos objetos (en nuestro ejemplo deben ser guardados en la base de datos y enviados a un correo), por lo tanto se requiere de crear objetos que inserten, actualicen, borren, etc. la información de esos objetos en la base de datos, en el argot tecnológico este tipo de capa se le llama Data Access Object (DAO). Al separar los objetos que gestionan la información en la base de datos de los modelos les permitirá en un futuro cambiar la tecnología, por ejemplo para .NET o Java podrían utilizar una librería que se llama hibernate para manejar la gestión de las operaciones en la base de datos y si en el futuro deben cambiar de libreria solo tienen que cambiar esa capa y no el resto de la aplicación (ya ven la ventaja?).
Ahora nuestra siguiente capa, es la que manejará las reglas del negocio específicas, es decir, debe calcular algo entre campos?, validar algo?, etc. Esta es nuestra capa de los servicios (en algunos casos le llaman Business Objects, otros le llaman Services Objects) pero estos conversan con los DAOs para manipular información específica entre los datos que entran en el sistema y la información de como debe ser manejada. En algunas ocasiones cuando no hay reglas de negocios específicas se puede acceder directamente a los DAOs sin tener una capa de servicios, pero yo recomiendo no saltarse esta capa por las razones expuestas arriba, puedo cambiar de base de datos, controladores de base de datos, tecnología y solo debería cambiar los DAOs mas no asi los servicios.
Y ahora nuestra capa de control, esta capa es la que agrupará todos los objetos que deben gestionar nuestro flujo de navegación del sistema, es decir, dependiendo de lo que nos devuelva los services entonces debe ir a una página específica o enviar información de vuelta a la interface gráfica. Por ejemplo, si el usuario se registra como cliente premiun debe ir a una página (previa inserción en la base de datos por el DAO y validación por el service, etc.) y si es otro tipo de usuario debe enviar un correo. Bueno, el asunto es que esta capa controla el flujo de a donde debe ir y que debe retornar al usuario.
Por último tenemos la capa de la vista, esta capa es la que mostrará la información al usuario como resultado de alguna operación o cambios en el sistema, esta capa usualmente está relacionada intimamente con el lenguaje a utilizar para el despliegue de la información en el sistema. Si es una página web esta capa gestiona la información de cómo debe enviarse y cómo debe visualizarse (ya sean botones, mensajes, cajas de dialogo, etc.)
En algunas aplicaciones web mas complejas se agrega una capa intermedia entre la vista y los controladores, esta capa es la de los web services que como están de moda se usan los restful que son los más estándares para convesar entre el lenguaje que se utiliza en la capa vista y la capa de control.
En resumen se tienen las siguientes capas:
1. Modelo.
2. Data Access Object
3. Services (opcional)
4. Controllers
5. Web Services (opcional)
6. Vista o Interface de usuario.
Al tener separada nuestra aplicacion de esta forma es seguro que si el día de mañana hay que cambiar algo no hay que hacerlo en todo el sistema y solo se hace en pocos componentes y tu aplicación es mucho más facil de entender.
Saludos!
Comentarios
Publicar un comentario