Para una empresa especializada en el desarrollo web a medida como lo es OBSolutions, es importante realizar los desarrollos lo más rápido posible para poder minimizar los tiempos de desarrollo y en consecuencia los costes de cada proyecto web.
Para acelerar nuestros desarrollos web a medida sin perder ni un ápice de calidad, hemos mejorado nuestro framework personal para que nos sea muy fácil crear una estructura básica donde empezar a desarrollar las funcionalidades de cada proyecto.
Para tener esta estructura básica, necesitamos crear todas las clases de transferencia de datos ( Value Objects o VO ) y todas las clases de acceso a los datos de la base de datos ( Data Access Objects o DAO ), así como los Controladores ( Controllers ) y las clases de negocio ( Business Objects o BO ). Pero hacer esto para cada proyecto desde cero es laborioso y lento. Por eso, hemos intentado automatizar la creación de algunos de los objetos que suelen seguir una estructura parecida.
Value Objects
Normalmente todos los VOs suelen ser muy parecidos: una clase contenedora de variables privadas con getters y setters para obtenerlas o modificarlas. Además, normalmente suelen representar una tabla de base de datos con una variable por columna.
Data Access Objects
Los DAOs pueden variar bastante más entre si, pero todos suelen tener y necesitar cuatro funciones típicas: crear, leer, modificar y borrar (también llamadas CRUD, de las siglas en inglés). Otra función que suele estar a menudo, seria la llamada elementoExistente()
, que nos indicaría si un elemento ya existe en base de datos.
Autogenerar VOs y DAOs
Antes de autogenerar ningún fichero, necesitamos saber todas las funcionalidades del proyecto y así poder diseñar su base de datos. Con esa base de datos ya podremos autogenerar un VO y un DAO para cada una de las tablas.
El código de autogeneración consultará tabla por tabla e irá creando las variables, los getters y los setters
a partir de unas plantillas. El proceso de autogeneración lo explicaremos en próximas entradas.
Además, al crear los VOs de forma automática, no escatimamos en información, así que para cada variable, aprovechamos para poner un comentario PHPDoc que nos indique a qué tabla hace referencia, el tipo de la columna ( varchar, int… ) y el valor por defecto, entre otras.
Con los DAOs, el proceso es el mismo, pero más sencillo, ya que las columnas de las tablas no afectarán a su autogeneración.
Estos Value Objects y Data Access Objects autogenerados, además de permitir poder integrar las clases al resto del código de forma rápida, deberían ser tolerantes a los cambios que se vayan haciendo en base de datos a posteriori. Es decir, que si hacemos algún cambio en base de datos, debería bastar con regenerar los ficheros y sustituirlos, el resto del código debería seguir funcionando.
Estructura flexible
Para conseguir esto necesitamos 3 ficheros para los Value Objects y 3 para los DAOs. Veamos un ejemplo para los VOs:
ValueObject es una clase abstracta con algunas funciones estrictamente necesarias, así que, cualquier clase de transporte de datos que creemos, deberá extender de ésta.
AFurnitureVo es una clase autogenerada de tipo abstracta, por tanto, no se podrá instanciar y deberá ser extendida para ser usada.
FurnitureVo es una clase creada manualmente que deberá extender de la clase abstracta autogenerada.
Creando la clase FurnitureVo totalmente vacía, ya podríamos utilizarla para la mayoría de los casos de uso, pero a veces necesitaremos ampliarla con más funciones. De hecho, en este punto es donde toma sentido realizar esta estructura, ya que podremos ampliar todo lo que queramos la clase FurnitureVo con nuevas funciones que no tienen porque ir estrictamente ligadas a la tabla de la base de datos. De esta manera, si cualquier día debemos añadir nuevos campos en la tabla furniture de la base de datos, podremos auto-regenerar AFurnitureVo sin perder ninguna de las ampliaciones que habremos hecho en FurnitureVo.
En futuras entradas comentaremos la estructura de 3 ficheros de los DAOs, que es prácticamente idéntica, pero aprovecharemos para comentar como podemos hacer que los CRUDs sean totalmente genéricos.
Esperamos que os haya gustado la explicación y no dudéis en compartir con nosotros vuestros sistemas para acelerar los desarrollos web a medida.