2009-09-26 8 views
7

Me pregunto acerca de algunas ideas que pueden mejorar el proceso de diseño de soluciones usando Access y el lenguaje de programación de VBA. Por supuesto, no estoy hablando de las mejores prácticas de programación en general, sino solo de las relacionadas directamente con Access y VBA.Mejores prácticas en programación de acceso

Todo el mundo sabe que VBA tiene una compatibilidad de programación orientada a objetos pobre, no hay herencia, polimorfismo, etc. Entonces, ¿cómo asegurar DRY y KISS a la vez? Existen algunas soluciones para implementar patrones y estrategias comunes en otros idiomas en VBA, pero francamente, a menudo son demasiado complicados. ¿Cuáles de esos vale la pena implementar?

Antes de comenzar un nuevo proyecto de Access (si hay alguno;)), deseo recopilar una colección de mejores prácticas, porque desde mi experiencia sé que con VBA en Access (y con Access en sí mismo) es muy difícil evitar malos conceptos de diseño y para terminar con código desordenado, ilegible y repetido varias veces.

+2

Solo quiero decir que esta es una gran pregunta. Se requiere mucha disciplina para evitar el acceso DRY pero se puede hacer. Pero no hay absolutamente nada que impida mezclar la lógica de ui y biz. Pero creo que es importante recordar que THE point of access es un desarrollo extremadamente rápido. Access es la plataforma de desarrollo más rápida para el desarrollo de aplicaciones de Windows. Entonces tiene un lugar. Seth –

Respuesta

2

Me gustaría agregar aquí algunas otras preguntas y respuestas relacionadas de una u otra manera con el mismo problema. Los indicadores pueden dar lugar a mi propia respuesta a estas preguntas, ¡pero no dude en buscar las respuestas de otros!

MS Access as enterprise software

Best way to test an MS-Access application

Working with multiple programmers on MS-Access

Recommendations on using SQL server GUIDS from MS-Access

Debo admitir que una de las principales limitaciones de acceso es el modelo de objeto limitado. Me molestó específicamente la falta de posibilidades de agregar mis propias propiedades y métodos al objeto Form.Hace poco encontré una respuesta eficaz a este problema mediante la creación de 2 objetos adicionales:

  • el objeto "AllMyForms", que de hecho mantener 2 colecciones de objetos: una es la colección de formularios de acceso estándar, el otro es un colección de todas las instancias del objeto "customForm". Ambas colecciones están indexadas con la propiedad hwnd de una forma abierta (o, para ser más específico, la propiedad hwnd de la instancia de un formulario, lo que me permite abrir varias instancias de la misma forma).

  • el objeto "customForm", que enumera mis propiedades y métodos de instancia de una forma

De esta manera personalizados, que puede referirse a propiedades tales como:

accessForms: refiriéndose a las propiedades y métodos estándar

AllMyForms.accessForm(hwnd).name 

se refiere a la .nam e propiedad del formulario de acceso a través de su valor .hwnd

Por cierto, la siguiente Debug.Print entonces dame el mismo resultado:

? screen.ActiveForm.name 
? AllMyForms.accessForm().name 'default value for hwnd is screen.activeForm.hwnd' 

formas personalizadas: propiedades

AllMyForms.customForm(hwnd).selectClause 

se referirá a la cláusula SELECT utilizada para crear el conjunto de registros subyacente de la instancia del formulario

Formas personalizadas: métodos

El método .agregate, disponible para un objeto customForm, calculará la suma/min/max/avg de un formulario "columna" (es decir, la suma de valores para un control en forma continua) :

AllMyForms.customForm().agregate("lineAmount","sum") 

me dará la suma de todos los valores "lineAmount" que aparecen en la instancia actual/activo de una forma.

+0

Supongo que su punto acerca de las propiedades/métodos del cliente es que no puede agregarlos todos en un solo lugar, es decir, que por defecto debe agregarlos en el módulo de clase de cada formulario. Pero esto se puede lograr con un envoltorio de módulo de clase independiente alrededor de sus formularios, y parece que eso es precisamente lo que ha hecho. ¿Puedes aclarar eso? –

+0

Si bien entiendo el valor de la envoltura de customForm(), no puedo ver el valor de su colección de formularios personalizados. No veo qué está proporcionando que no esté disponible con las colecciones de Access existentes. –

+0

Algunas aclaraciones: la idea básica es poder agregar mis propias propiedades/métodos a los formularios (es decir, las instancias de los formularios de acceso). Tengo un procedimiento único para abrir una instancia de este tipo, con un método "allMyForms.open myFormName, mySelectQuery (if any), etc".Cada vez que se llama a este método, agregaré un miembro a la colección privada o_AccessForms, que es una nueva instancia de un formulario existente. También agregaré un miembro a la colección o_CustomForms, que es una nueva instancia de mi objeto "customForm". Al hacer esto, puedo acceder tanto a las propiedades estándar como a las propiedades personalizadas de mis formularios abiertos. –

2

La fuente definitiva de las mejores prácticas en la programación de acceso es este libro:

acceso Manual de 2002 de escritorio desarrollador
http://www.amazon.com/Access-2002-Desktop-Developers-Handbook/dp/0782140092

Debe obtener una copia si usted es serio acerca de la programación en Access. Estos chicos son los expertos.

Me doy cuenta de que el libro parece anticuado, pero toda la información que contiene todavía se aplica. Supongo que nunca se actualizó porque este tipo de desarrollo es un área de nicho. Pero Access no ha cambiado tanto internamente (es una de las únicas herramientas restantes de desarrollo de software que todavía usa lo que equivale a un dialecto de VB6), y la mayoría de la información en el libro sigue siendo buena.

El libro de acompañamiento que se centra en cliente/servidor de desarrollo está aquí: Manual

Access 2002 Empresa del desarrollador
http://www.amazon.com/Access-2002-Enterprise-Developers-Handbook/dp/0782140106

+0

Dos de mis libros favoritos de todos los tiempos. Tenía todas las ediciones de la primera. –

0

Una cosa que siempre tenía que hacer cuando lo hice la programación de acceso fue el uso de muchos campos ocultos por razones vinculantes. Me aseguré de hacer el campo invisible y también cambié el color del campo al primer plano blanco y rojo de fondo para que la gente supiera que se trataba de un campo oculto.

Otra buena práctica que utilicé fue el uso de módulos para todo mi código compartido. Adquiera el hábito de poner mucho de su código reutilizable en módulos.