Problemas de transmisión de datos en el acceso a bases de datos multiproceso de VC
Las operaciones COM tienen su propio conjunto de modelos entre subprocesos y entre procesos. Este es un modelo compuesto que derivará alrededor de 7 u 8 combinaciones. Aprender COM es imprescindible. El autor ha leído la función CoInitializeEx en el archivo de ayuda y puede entenderla un poco. Pero si no ha aprendido COM, simplemente mirar los archivos de ayuda en MSDN será como una niebla y es difícil de entender. Por lo tanto, se recomienda comprar un libro COM como referencia. En segundo lugar, en Internet, como CSDN, hay muchos modelos COM relacionados con procesos de subprocesos escritos por personas entusiastas, así como reglas de uso, ventajas y desventajas, etc. ¡puedes leerlos!
En MFC, es menos probable que se desarrolle el concepto de los peligros de pasar variables entre subprocesos. Entonces, en MFC, parece que podemos pasar variables entre subprocesos como queramos, pero en realidad ese no es el caso. En circunstancias normales, es mejor no operar directamente ventanas y controles creados por el hilo principal en otros subprocesos, sino dejar que el hilo principal que crea ventanas y controles opere ventanas y controles a través de la comunicación entre subprocesos.
Por lo tanto, esta limitación es muy obvia en COM. En COM, hay conceptos llamados MARSHAL, PROXY y STUB. Estos conceptos, por supuesto, son principalmente conceptos relacionados con procesos. problema con algo que no fue creado por el hilo en sí, pero que no es utilizado por ese hilo.
El contenido de la interfaz como VIEW no se puede pasar casualmente a subprocesos que no son de interfaz (como subprocesos de trabajo).
Mi sugerencia:
Cree subprocesos de trabajo porque las operaciones de la base de datos y los datos devueltos desde la base de datos al nivel del programa deben reprocesarse, y todos estos pasos pueden consumir mucho tiempo y debe colocarse en Las operaciones que consumen mucho tiempo en el subproceso de la interfaz evitarán que el subproceso de la interfaz procese mensajes WM_XXX, lo que provocará que la interfaz se cuelgue. Por lo tanto, operaciones como los punteros inteligentes se colocan en subprocesos de trabajo y se administran de forma independiente. El subproceso de trabajo obtiene datos de la base de datos a través de punteros inteligentes, luego los procesa y almacena los resultados de los datos en lugares acordados en el programa, como variables globales, memoria virtual y otros lugares. Una vez completado el procesamiento de datos, se enviará un mensaje personalizado al hilo de la interfaz para que el hilo de la interfaz pueda mostrar los datos guardados en la interfaz en forma de un mensaje personalizado. También hay una función para enviar mensajes del hilo, a saber, PostThreadMessage. .
Hay otros detalles sutiles a considerar, como si crear tus propios hilos o utilizar un grupo de hilos. Con la acumulación de experiencia podrás considerar muchas cuestiones. La clave es aprender bien los conocimientos teóricos y la práctica no puede faltar.
La última es una modificación conceptual de _ConnectionPtr, que es una clase estándar de C++. Las clases de C++ pueden sobrecargar el operador ->, que es un operador de puntero sobrecargado. Hace que las variables instanciadas a través de la clase se comporten más como punteros que como variables ordinarias cuando realmente se usan. Es este operador de puntero sobrecargado el que es un puntero inteligente, no la clase _ConnectionPtr. . La clase _ConnectionPtr es, en el mejor de los casos, solo una clase de puntero inteligente. También he visto una traducción de un puntero inteligente. El texto original en inglés es SMART POINTER.