Proyectos
Última actualización
Última actualización
Los contenedores de objetos son la pieza clave en el diseño de la arquitectura de nuestras aplicaciones. Por este motivo es bueno tener presentes algunas recomendaciones a la hora de crear aplicaciones con mayor o menor complejidad.
La longitud del nombre o descripción de un proyecto no es un problema en sí, sin embargo la longitud del nombre nos afectará a la hora de poder ver los identificadores “completos” de los objetos. Por este motivo, debemos usar el criterio menos es más. En la siguiente imagen podemos observar que el identificador del objeto se puede leer entero.
Sin embargo, si el nombre del proyecto fuese “Gestión Integrada de Automoción” ya no entraría en este espacio. El resultado es que tendríamos que hacer muy ancho el dock donde se muestran las propiedades de un objeto.
Por este motivo, es recomendable usar o nombres cortos, siglas o abreviaturas que permitan reducir el tamaño del nombre del proyecto. El que existan varios proyectos con el mismo nombre, no supone un problema funcional debido a que a nivel interno se utiliza el “id del fichero” y no su nombre. Sin embargo, no es conveniente tener nombres duplicados ya que cuando los veamos juntos en un mismo esquema no podremos diferenciarlos de forma directa.
En el nombre de los proyectos se pueden dejar espacios en blanco entre las diferentes palabras, es conveniente que el equipo establezca el criterio de utilizar o no espacios en blanco para conseguir que todos los proyectos se creen con el mismo criterio.
Es conveniente añadir un sufijo al nombre del proyecto indicando si se trata de aplicación o datos, en esta guía utilizamos los sufijos “app” y “dat” respectivamente. Sin embargo, se puede utilizar prefijos más cortos como “a” y “d”.
El motivo por el que conviene utilizar estos sufijos está relacionado con la posibilidad de crear el mismo objeto en cualquier tipo de proyecto, por ejemplo podemos crear un proceso en el proyecto de aplicación o datos, si llamamos igual a ambos proyectos no podríamos saber cuando vemos el identificador del objeto donde podremos encontrarlo.
El alias es un datos “obligatorio” que no debemos olvidarnos de cubrir, ya que se utilizará en diferentes ámbitos de la aplicación, sobre todo al crear scripts de JavaScript en el que los identificadores de los objetos se componen utilizando el alias del proyecto que lo contiene y el identificador del propio objeto. Por este motivo la recomendación es añadir el alias al proyecto en el mismo momento de su creación.
No recomendable | Motivo |
Gestión Integrada | No identifica si es de datos o aplicación. |
Gestión Integrada #1 app | Usa caracteres especiales. |
Gestión Integrada para Industrias Derivadas del Proceso Lácteo app | Demasiado largo. |
Recomendable | Motivo |
Ejemplosa_GESINT_app | Corto, único, con sufijo de tipo y sin espacios. |
eGESINT dat | Corto, único, con sufijo de tipo y con espacios. |
vERP_2_app | Corto, único, con sufijo de tipo y sin espacios. |
Aquí encaja perfectamente el principio de menos es más. Si podemos tener un único proyecto de datos será más fácil de programar, mantener y evolucionar.
Aplicando una organización de encarpetado por módulo.
Dentro de cada módulo podremos crear subcarpetas con las tablas del mismo. Con esta organización si mañana queremos mover todas las tablas de un módulo a otro proyecto podremos hacerlo con un cortar y pegar.
Hay varios motivos por los que es necesario crear más de un proyecto de datos:
Cuando tenemos un núcleo estándar para todas nuestras aplicaciones que no queremos tocar ni engordar con funcionalidades específicas de cada cliente o sector, y sobre ese núcleo desarrollamos una solución personalizada para un cliente o sector. En este caso se suele crear un proyecto de datos con las tablas específicas para ese cliente o sector que hereda del proyecto de datos del núcleo. Esto nos obligará a tener una instancia de datos para cada proyecto.
Cuando un proyecto va a contener tablas comunes a múltiples empresas, en este caso se crea una única instancia de datos para esas tablas comunes y para los datos específicos de cada empresa se crea un proyecto que heredado del de tablas comunes y que se instanciará una vez por cada empresa. Para poder crear esta estructura de instancias necesitaremos dos o más proyectos de datos.
