excel - ¿Existen desventajas al poner código en Userforms en lugar de módulos?

vba user-interface

Question

¿Hay desventajas en poner código en un formulario de usuario de VBA en lugar de en un módulo "normal"?

Esta podría ser una pregunta simple, pero no he encontrado una respuesta concluyente al buscar en la web y stackoverflow.

Antecedentes: estoy desarrollando una aplicación front-end de una base de datos en Excel-VBA. Para seleccionar diferentes filtros tengo diferentes formas de usuario. Pregunto qué diseño de programa general es mejor: (1) poner la estructura de control en un módulo separado O (2) poner el código para la siguiente forma de usuario o acción en la forma de usuario .

Hagamos un ejemplo. Tengo un botón Active-X que activa mis filtros y mis formularios.

Variante1: Módulos

En el CommandButton:

Private Sub CommandButton1_Click()
  call UserInterfaceControlModule
End Sub

En el modulo:

Sub UserInterfaceControllModule()
Dim decisionInput1 As Boolean
Dim decisionInput2 As Boolean

UserForm1.Show
decisionInput1 = UserForm1.decision

If decisionInput1 Then
  UserForm2.Show
Else
  UserForm3.Show
End If

End Sub

En la variante 1, la estructura de control está en un módulo normal. Y las decisiones sobre qué formulario de usuario mostrar a continuación se separan del formulario de usuario. Cualquier información necesaria para decidir qué formulario de usuario mostrar a continuación debe extraerse del formulario de usuario.

Variante2: Forma de usuario

En el CommadButton:

Private Sub CommandButton1_Click()
  UserForm1.Show
End Sub

En Userform1:

Private Sub ToUserform2_Click()
  UserForm2.Show
  UserForm1.Hide
End Sub

Private Sub UserForm_Click()
  UserForm2.Show
  UserForm1.Hide
End Sub

En la Variante 2, la estructura de control está directamente en los formularios de usuario y cada formulario de usuario tiene las instrucciones sobre lo que viene después.

He comenzado el desarrollo utilizando el método 2. Si esto fue un error y hay algunos inconvenientes serios para este método, quiero saberlo más pronto que tarde.

Answer 1

Descargo de responsabilidad Escribí el rubberduckvba.wordpress.com/2017/10/25/userform1-show Victor K se unió . Soy dueño de ese blog y administro el proyecto de complemento VBIDE de código abierto para el que es.

Ninguna de sus alternativas es ideal. Volver a lo básico.

Para seleccionar diferentes filtros, tengo diferentes formas de usuario (sic).

Sus especificaciones exigen que el usuario necesite poder seleccionar diferentes filtros, y usted elige implementar una interfaz de usuario para ello mediante un UserForm . Hasta ahora, todo bien ... y todo es cuesta abajo desde allí.

Hacer que el formulario sea responsable de cualquier otra cosa que no sean problemas de presentación es un error común, y tiene un nombre: es el patrón Smart UI [anti], y el problema es que no se escala . Es excelente para la creación de prototipos (es decir, hacer una cosa rápida que "funcione" - tenga en cuenta las citas de miedo), no tanto para cualquier cosa que deba mantenerse durante años.

Probablemente haya visto estos formularios, con 160 controles, 217 controladores de eventos y 3 procedimientos privados que se cierran en 2000 líneas de código cada uno: así de mal se escala la interfaz de usuario inteligente , y es el único resultado posible en ese camino.

Verá, un UserForm es un módulo de clase: define el plano de un objeto . Los objetos generalmente quieren ser instanciados , pero alguien tuvo la genial idea de otorgar a todas las instancias de MSForms.UserForm una ID predeclarada , que en términos COM significa que básicamente obtienes un objeto global de forma gratuita.

¡Excelente! ¿No? No.

UserForm1.Show
decisionInput1 = UserForm1.decision

If decisionInput1 Then
  UserForm2.Show
Else
  UserForm3.Show
End If

¿Qué sucede si UserForm1 es "X''d-out"? ¿O si UserForm1 es Unload ed? Si el formulario no maneja su evento QueryClose , el objeto se destruye, pero debido a que esa es la instancia predeterminada , VBA crea automáticamente / silenciosamente uno nuevo para usted, justo antes de que su código lea UserForm1.decision , como resultado obtiene lo que sea El estado global inicial es para UserForm1.decision .

Si no se trataba de una instancia predeterminada , y QueryClose no se manejaba, acceder al miembro .decision de un objeto destruido le daría el clásico error 91 en tiempo de ejecución para acceder a una referencia de objeto nulo.

UserForm2.Show y UserForm3.Show hacen lo mismo: disparar y olvidar: pase lo que pase, y para averiguar exactamente en qué consiste, debe desenterrarlo en el código subyacente respectivo de los formularios.

En otras palabras, los formularios están ejecutando el programa . Son responsables de recopilar los datos, presentarlos, recopilar las aportaciones de los usuarios y hacer cualquier trabajo que se necesite hacer con ellos . Es por eso que se llama "Smart UI": la IU lo sabe todo.

Hay una mejor manera MSForms es el ancestro COM del marco de UI WinForms de .NET, y lo que el ancestro tiene en común con su sucesor .NET es que funciona particularmente bien con el famoso patrón Model-View-Presenter (MVP).

El modelo

Esa es tu información . Esencialmente, es lo que la lógica de su aplicación necesita saber fuera del formulario.

• UserForm1.decision vamos con eso.

Agregue una nueva clase, FilterModel , por ejemplo, FilterModel . Debería ser una clase muy simple:

Option Explicit

Private Type TModel
    SelectedFilter As String
End Type
Private this As TModel

Public Property Get SelectedFilter() As String
    SelectedFilter = this.SelectedFilter
End Property

Public Property Let SelectedFilter(ByVal value As String)
    this.SelectedFilter = value
End Property

Public Function IsValid() As Boolean
    IsValid = this.SelectedFilter <> vbNullString
End Function

Eso es realmente todo lo que necesitamos: una clase para encapsular los datos del formulario. La clase puede ser responsable de alguna lógica de validación, o lo que sea, pero no recopila los datos, no los presenta al usuario y tampoco los consume . Son los datos.

Aquí solo hay 1 propiedad, pero podría tener muchas más: piense en un campo en el formulario => una propiedad.

El modelo también es lo que el formulario necesita saber de la lógica de la aplicación. Por ejemplo, si el formulario necesita un menú desplegable que muestre varias selecciones posibles, el modelo sería el objeto que las exponga.

La vista

Esa es tu forma. Es responsable de conocer los controles, escribir y leer del modelo , y ... eso es todo. Estamos viendo un diálogo aquí: lo presentamos, el usuario lo llena, lo cierra y el programa actúa sobre él: el formulario en sí no hace nada con los datos que recopila. El modelo podría validarlo, el formulario podría decidir deshabilitar su botón Aceptar hasta que el modelo diga que sus datos son válidos y que están listos, pero bajo ninguna circunstancia un UserForm lee o escribe desde una hoja de trabajo, una base de datos, un archivo, una URL, o algo.

El código subyacente del formulario es muy simple: conecta la interfaz de usuario con la instancia del modelo y activa / desactiva sus botones según sea necesario.

Las cosas importantes para recordar:

• Hide , no Unload : la vista es un objeto y los objetos no se autodestruyen.
• NUNCA consulte la instancia predeterminada del formulario.
• Siempre maneje QueryClose , nuevamente, para evitar un objeto autodestructivo ("X-out" del formulario destruiría la instancia).

En este caso, el código subyacente podría verse así:

Option Explicit
Private Type TView
    Model As FilterModel
    IsCancelled As Boolean
End Type
Private this As TView

Public Property Get Model() As FilterModel
    Set Model = this.Model
End Property

Public Property Set Model(ByVal value As FilterModel)
    Set this.Model = value
    Validate
End Property

Public Property Get IsCancelled() As Boolean
    IsCancelled = this.IsCancelled
End Property

Private Sub TextBox1_Change()
    this.Model.SelectedFilter = TextBox1.Text
    Validate
End Sub

Private Sub OkButton_Click()
    Me.Hide
End Sub

Private Sub Validate()
    OkButton.Enabled = this.Model.IsValid
End Sub

Private Sub CancelButton_Click()
    OnCancel
End Sub

Private Sub UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)
    If CloseMode = VbQueryClose.vbFormControlMenu Then
        Cancel = True
        OnCancel
    End If
End Sub

Private Sub OnCancel()
    this.IsCancelled = True
    Me.Hide
End Sub

Eso es literalmente todo lo que hace la forma. No es responsable de saber de dónde provienen los datos o qué hacer con ellos .

El presentador

Ese es el objeto "pegamento" que conecta los puntos.

Option Explicit

Public Sub DoSomething()
    Dim m As FilterModel
    Set m = New FilterModel
    With New FilterForm
        Set .Model = m ''set the model
        .Show ''display the dialog
        If Not .IsCancelled Then ''how was it closed?
            ''consume the data
            Debug.Print m.SelectedFilter
        End If
    End With
End Sub

Si los datos en el modelo debían provenir de una base de datos, o alguna hoja de trabajo, utiliza una instancia de clase (sí, ¡ otro objeto!) Que es responsable de hacer exactamente eso.

El código de llamada podría ser el controlador de clics de su botón ActiveX, activar el presentador y llamar a su método DoSomething .

Esto no es todo lo que hay que saber sobre OOP en VBA (ni siquiera mencioné interfaces, polimorfismo, trozos de prueba y pruebas de unidad), pero si desea un código objetivamente escalable, querrá ir por el agujero del conejo MVP y explore las posibilidades que el código verdaderamente orientado a objetos trae a VBA.

TL; DR:

El código ("lógica empresarial") simplemente no pertenece al código subyacente de los formularios, en ninguna base de código que signifique escalar y mantenerse durante varios años.

En la "variante 1", el código es difícil de seguir porque está saltando entre los módulos y las preocupaciones de la presentación se mezclan con la lógica de la aplicación: no es el trabajo del formulario saber qué otro formulario mostrar se presionó el botón A o el botón B. En su lugar, debe permitirle al presentador saber qué quiere hacer el usuario y actuar en consecuencia.

En la "variante 2", el código es difícil de seguir porque todo está oculto en el código subyacente de las formas de usuario: no sabemos cuál es la lógica de la aplicación a menos que profundicemos en ese código, que ahora mezcla intencionalmente las preocupaciones de presentación y lógica empresarial. Eso es exactamente lo que hace el antipatrón "Smart UI".

En otras palabras, la variante 1 es ligeramente mejor que la variante 2, porque al menos la lógica no está en el código subyacente, pero sigue siendo una "IU inteligente" porque está ejecutando el programa en lugar de decirle a la persona que llama lo que está sucediendo .

En ambos casos, la codificación contra las instancias predeterminadas de los formularios es perjudicial, ya que pone el estado en un alcance global (cualquiera puede acceder a las instancias predeterminadas y hacer cualquier cosa en su estado, desde cualquier parte del código).

Trata las formas como los objetos que son: ¡ejemplifícalas!

En ambos casos, debido a que el código del formulario está estrechamente relacionado con la lógica de la aplicación y entrelazado con las preocupaciones de presentación, es completamente imposible escribir una sola prueba unitaria que cubra incluso un solo aspecto de lo que está sucediendo. Con el patrón MVP, puede desacoplar completamente los componentes, abstraerlos detrás de las interfaces, aislar responsabilidades y escribir docenas de pruebas unitarias automatizadas que cubren cada pieza de funcionalidad y documentan exactamente cuáles son las especificaciones, sin escribir un solo bit de documentación: El código se convierte en su propia documentación .