0317.Sure Step 2012

Organización en Dexterity

Cuando se comienza un proyecto nuevo de Dexterity basado en un diccionario existente de Microsoft Dynamics GP, aparecen en el explorador de recursos todos y cada uno de los objetos libres de la aplicación. En el instante en que el programador crea recursos nuevos, aparecen en el listado de http://www.tiiselam.com/ así como los recursos originales de la aplicación. Microsoft Dynamics GP solo en el diccionario de primordial tiene más de mil ochocientos formas, mil doscientos reportes, mil seiscientos tablas, sin contar los modelos de datos, formatos, campos, las incesantes, y considerablemente más géneros de objetos.

El hecho que los recursos propios estén mezclados con los originales de la aplicación vuelve un tanto complicado la busca. Claro que Microsoft Dynamics GP tiene organizado cada objeto con una nomenclatura basada en el módulo que deberíamos continuar.

Podemos ver más detalle del listado de módulos en la documentación del SDK que se halla en el instalador de la aplicación (Aconsejo descargar el SDK actualizado de la página de Microsoft debido a que se actualiza frecuentemente con cada liberación y hotfix).dexterity

Las formas tienen un nombre técnico (Nota: no confundir formas de Dexterity con formas de Visual Studio. El equivalente de formas de Visual Studio en Dexterity son las ventanas que son los objetos que se halla en las formas).

En donde MMM representa el módulo, xxxxxxxxxx la operación y zzzzzzzzzz la acción. Por servirnos de un ejemplo, GL_Transaction_Entry, SOP_Item_Inquiry o bien POP_Invoice_Entry, no obstante, no es una regla… hallarán muchas salvedades asimismo. Considero buena práctica continuar esta regla.

Los reportes tratan de continuar una sintaxis de sufijo por módulo, no obstante, como el nombre del reporte es usado para visualizarlo al usuario final, se ven muchos nombres gráficos, con lo que si no se conoce bien la aplicación puede ser un tanto complicado localizar un reporte en el listado. Puede ser organizado por serie el listado, mas asimismo hallarán muchos de ellos organizado por módulo. Incluso de esta manera, considero buena práctica incluir el sufijo del módulo en el nombre del reporte.
Las tablas tienen una historia interesante. En contraste a las formas y los reportes tienen tres nombres. Un nombre técnico, uno de visualización y uno físico. A nivel de organización son esenciales los nombres técnico y físico. No deseo decir con esto que el no poner el prefijo en el nombre de visualización no es esencial (es costumbre mía hacerlo para facilitar al usuario distinguir las tablas).

En donde MMM representa el módulo, Xxxxxxxx la descripción y ZZZZ la utilidad. Ejemplos de la utilidad son HDR encabezado de transacciones, LINE líneas de detalle de transacciones, SETP configuración, MSTR datos maestros, WORK operaciones de trabajo, HIST operaciones históricos, etc…
El nombre físico es en donde viene la confusión. Es el nombre con el que se ve la tabla representada en la base de datos y en general está representada por no más de ocho caracteres. Tiene su origen en las primeras versiones de Dexterity en donde se aguantaba otras base de datos de tipo ISAM (Indexed Sequential Access Method) como C-Tree y Pervasive (Btrieve) que tenían sus datos basados en ficheros en el archivo system en la temporada de FAT, con lo que los nombres de las tablas estaban limitados a ocho caracteres y su respectiva extensión.

En donde MMM representa el módulo, XX es cero si se trata de una tabla de profesor, diez de trabajo, veinte abierto, treinta histórico, cuarenta configuración y ZZZ un secuencial. Claro que si el programador quiere usar exactamente el mismo nombre técnico como nombre físico asimismo puede hacerlo, mas para esto debe habilitar una alternativa en Dexterity que habilita nombres de tablas largos. Pueden habilitar la opción en Editar->Options->Allow Long Physical Table Names.
Una vez visto estos pequeños consejos de nomenclatura y definido el nombre del módulo o bien prefijo de la aplicación propia que se marcha a desarrollar, se puede organizar de mejor manera el programa. No aconsejo emplear exactamente los mismos prefijos que usa Microsoft. Siempre y en todo momento definan sus prefijos para sus aplicaciones. Ciertos ISV tienen siempre y en todo momento fijos el nombre de sus empresas como estándar.

Como último paso es acotar los Worksets y asignarles los recursos. Esto consiste en crear áreas de trabajo adaptados para no tener mezclados los recursos propios o bien cambiados con los originales de la aplicación. Se pueden delimitar cualquier cantidad de Worksets, no obstante, tengo la costumbre de delimitar para proyectos no muy grandes uno para formas, uno para reportes y otro para tablas.

Hay otras acciones que se efectúan para organizar el código mas es de forma externa, debido a que programo mucho de forma híbrida, en donde utilizo Visual Studio Tools con C# y creo clases vinculandolos con los acontecimientos de Dexterity. Mas este es un tema fuera de covertura pues ya se trata de Visual Studio. Asimismo está la creación de los stored procedures, que sostengo con exactamente la misma sintaxis.

Espero que estos consejos les sirva de guía para sostener el código en Dexterity un tanto más organizado. Cualquier sugerencia auxiliar es bienvenida!!!

Categories: Empresas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *