El uso adecuado de una instancia de clase

Question

Estoy utilizando Access 2003 VBA para procesar los datos recursiva para listas de materiales de fabricación. He construido un módulo de clase a dejar que mis principales tablas tienen alcance estático. Esto parece simplificar la recursividad - me libera de contar los niveles de abajo y arriba de nuevo ya que recorrer una lista de materiales. No estoy abriendo el mismo conjunto de registros de forma redundante; Estoy filtrar una gran cantidad en su lugar.

Después de conseguir este curso he leído acerca de modelado de objetos-Relación y decidieron instancia no un conjunto de registros, sino un registro. A continuación, los campos de ese registro podría ser propiedades. Después de mucho trabajo y muchas emociones de la victoria que en su mayoría eran equivocados, me di cuenta de este enfoque no tiene beneficios porque Access está basado en tablas.

Mis módulos de clase siguen ayudando como antes. Mi pregunta es acerca de dos versiones alternativas a continuación. El primero utiliza dos instancias (padre, niño). El segundo utiliza una y luego se vuelve a utilizar. Obviamente, la primera de ellas es influenciada-ORM.

¿Hay alguna razón para elegir uno de ellos sobre el otro? Además, tenga en cuenta las cursivas línea al final: Si yo no necesito eso (porque no necesito más información sobre el Padre), ¿cambia la respuesta? ¿Puede alguien ayudarme con mi pensamiento general?

(Tenga en cuenta que cierro los conjuntos de registros, pero no las instancias de clase. Mi opinión es que los casos de VBA se cierran y dejarlos hacer que la práctica es aceptada. Parece que he tomado pseudo-código para nuevos niveles de seudo ... el objetivo es claridad, espero que funcione.)

    VERSION 1 
    Property Sub ReviewPart ( Parent_Part_ID )

    Get Parent_Part_ID
    Create instance of Class --> Get recordset
    Filter Class recordset ( Parent_Part_ID )
    Exploit Class recordset
    See if Parent_Part_ID has Childs
    If it does:
       Open recordset of Childs
       For each Child
         Get Child_Part_ID
         Create instance of Class --> Get recordset
         Filter Class recordset ( Child_Part_ID )
         Exploit Class recordset
         See if Child_Part_ID has Childs
         If it does:  
           Instance New ReviewPart ( Child_Part_ID )
         Otherwise:
         Nothing; Move On
       Next Child
       Close recordset of Childs
    Otherwise:
       Move On
    Exploit Class recordset ( still points to parent )
 
    
    VERSION 2
    Property Sub ReviewPart ( Parent_Part_ID )

    Get Parent_Part_ID
    Create instance of Class --> Get recordset
    Filter Class recordset ( Parent_Part_ID )
    Exploit Class recordset
    See if Parent_Part_ID has Childs
    If it does:
       Open recordset of Childs
       For each Child
         Get Child_Part_ID
         Create instance of Class --> Get recordset
         Filter Class recordset ( Child_Part_ID )
         Exploit Class recordset
         See if Child_Part_ID has Childs
         If it does:  
           Instance New ReviewPart ( Child_Part_ID )
         Otherwise:
         Nothing; Move On
       Next Child
       Close recordset of Childs
    Otherwise:
       Move On
    Filter Class recordset ( Parent_Part_ID )
    Exploit Class recordset ( still points to parent )

Answer 1

Parece que el primero le da una mejor facilidad de uso desde la perspectiva del programador, ya que uno puede simplemente comenzar con el registro que está interesado en y raíz fácilmente en los registros asociados con sólo acceder a las propiedades del registro que comenzó.

Por otra parte, este último parece ser más eficiente, ya que no es pesimista cargar todos los registros que podrían estar relacionados con la actual.

Un par de optimizaciones potenciales para el primer método que podría ayudar a que se acercan a la eficiencia de la segunda vez que mantiene la facilidad de uso:

• Sólo cargar los registros secundarios a medida que se necesitan. El uso de Get / Set descriptores de acceso le permitirá cargar los de arriba justo a tiempo, en lugar de todos a la vez cuando el registro padre se extrae de la base de datos.
• Como alternativa, utilice un JOIN para recuperar todos los datos secundarios a la vez como parte de una única consulta. Esto todavía le daría todos los datos precargados, pero reduciría el número de consultas que tienen que correr para conseguir sustancialmente.

La esperanza de que es un poco de ayuda.

Answer 2

¿Ha pensado en utilizar el proveedor MSDataShape y la sintaxis de SHAPE para producir de registros ADO jerárquicas ?