¿Cuándo debo mover el código de VBA de un módulo de formulario a un módulo separado?

Question

Tengo bastantes instancias en las que comienzo con un subformulario básico, luego tengo otros 3 subformularios que se basan en él, cada uno añadiendo algunos elementos diferentes a los básicos. Esto significa que tengo una página de códigos para cada subformulario, con muchas repeticiones. ¿Está bien colocar los elementos comunes en un módulo separado y dejar solo el código adicional relevante para cada subformulario en su página de códigos? ¿Hay algún problema de rendimiento con esto?

Answer 1

En cuanto a la última parte de su pregunta, "? ¿Hay problemas de rendimiento con este"

Hay 2 consecuencias Soy consciente de:

1. tiempo de carga del formulario
2. uso de memoria

Como ejemplo hipotético, imagine que tiene un formulario con un control de tabulación. Ese control de pestañas contiene 10 páginas, y cada página contiene un subformulario. Si esos subformularios incluyen copias del mismo código VBA, ese código común debe cargarse nuevamente para cada subformulario. Eso lleva tiempo y aumenta el uso de la memoria.

Si mueve el código común a un módulo estándar y lo referencia desde sus subformularios, necesita cargarlo solo una vez ... reduciendo tanto el tiempo de carga de formulario como el consumo de memoria.

El resultado neto es que el enfoque que está considerando podría hacer que su aplicación sea más receptiva ... lo que puede conducir a usuarios más felices.

Sin embargo, incluso si ese enfoque no produce una mejora notable en el rendimiento, aún así lo haría de todos modos, ya que significa que necesitará mantener una sola copia del código común.

Answer 2

Respuesta corta, sí, hazlo, divide el código que se repite entre cada uno de los formularios.

Respuesta larga, pero extraer el código que se repite en un módulo o clase por separado es, en mi opinión, la mejor manera de hacerlo.

Las clases hacen que su código sea más manejable y más fácil de mantener. Si tiene un código similar en varios lugares, dificulta el mantenimiento porque debe cambiarlo en cada ubicación. Tenerlo ubicado en un solo lugar hace que sea más fácil de administrar y mantener.

La lista de ventajas fue tomada desde un Chicago Access Users Group (CAUG) talk - "Class Modules in Access":

Advantages of using classes/objects: 
- let's you create more complex objects than tables or queries provide 
    alone 
- using classes within classes let's you restrict function visibility 
- class methods & attributes are more descriptive than module's 
    function list alone 
- let's you use Intellisense for more efficient coding 
- no "ambiguous name" errors with multiple copies of the same class 
    module 
- can copy class modules without worry of creating ambiguous function 
    names 
- static variables are implicit in class objects, and so are easier to 
    manage 
- isolating access layers within wrapper classes promote 
    portability/maintainability 
- better support for separation of UI/business logic/data access = 
    n-tier development 
- promotes modular thinking in analysis, design 
- easier to adapt many publicly-available object models to Access apps 
- prepares you for transition to .NET and other fully object-oriented 
    architectures 

Answer 3

Si estoy entender la pregunta, sí se puede centralizar una cierta cantidad de código moviéndolo en un módulo de código estándar. Probablemente haya varias formas de hacerlo, pero una de las mejores formas es pasar el objeto de formulario a sus funciones. He aquí un ejemplo:

Private Sub Form_BeforeUpdate(Cancel As Integer) 
    If ValidateContact = False Then Cancel = True 
End Sub 

'This code goes in a standard code module not associated with any form 
Public Function ValidateContact(ByRef frm as Form) as Boolean 
    Dim bValid as Boolean 
    bValid = True 
    If Nz(frm!FirstName, "") = "" Then 
     MsgBox "First Name cannot be blank." 
     bValid = False 
    ElseIf Nz(frm!LastName, "") = "" Then 
     MsgBox "Last Name cannot be blank." 
     bValid = False 
    End If 
    ValidateContact = bValid 
End Function 

Además, si he entendido bien tu eres cuestión no es en absoluto acerca del uso de módulos de clase/clase objetos, al menos no de forma explícita. (En verdad, básicamente cada bit de código que escribe en Access está haciendo uso de un objeto de clase, la mayoría de las veces implícitamente). Otro usuario de SO ya ha publicado una gran respuesta sobre los beneficios de usar objetos de clase en Access, por lo que no expondré mucho más en eso. En verdad, los módulos de código estándar son básicamente una clase Singleton que no tiene que ser instanciada como lo hace un objeto de clase. Hay razones por las que se prefieren los módulos de código único/estándar, al menos para algunas cosas, aunque solo sea por el simple hecho de que es más fácil llamar a las funciones. Sin embargo, si se encuentra escribiendo funciones que tienen cuatro o más argumentos, probablemente se beneficie al cambiarlo a un objeto de clase que le permita establecer propiedades antes de llamar a métodos relacionados.