Directorio de artículos
I. Introducción
Anteriormente escribí un artículo sobre singletons: Implementación del patrón singleton en C# , que hablaba sobre qué son los singletons y las implementaciones de código común en C#. El contenido de ese artículo era teórico y no práctico.
Recientemente estuve usando WPF para escribir una computadora host y descubrí que cuando usaba singletons en el desarrollo real, no me importaba su implementación subyacente y rara vez veía un código de clase singleton como este:
using System;
public sealed class Singleton
{
private static volatile Singleton instance;
private static object syncRoot = new Object();
private Singleton() {
}
public static Singleton Instance
{
get
{
if (instance == null)
{
lock (syncRoot)
{
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
}
En su lugar, a menudo se crea un contenedor de servicios (ServiceProvider), luego se agrega la clase en la que desea implementar un singleton en modo singleton y se hace público el contenedor de servicios (generalmente en la clase App) para que todo el código del programa pueda acceder a él. , cuando quieras usar el singleton, simplemente sácalo del contenedor:
public IServiceProvider Services {
get; }
private static IServiceProvider ConfigureServices()
{
var services = new ServiceCollection();
services.AddSingleton<Class>();
...
return services.BuildServiceProvider();
}
Si no ha utilizado este método de contenedor antes, puede que le resulte problemático, pero una vez que lo acepte, descubrirá que se convierte en una rutina. Casi cualquier aplicación puede hacer esto (este enfoque para los contenedores de servicios es en sí mismo un patrón de diseño IOC).
Estos contenidos no son de lo que hablará este artículo. Este artículo quiere hablar principalmente sobre la aplicación de singletons en programas de computadora host y cómo usarlos en un escenario.
2. Escenario de aplicación de caso único de PC
2.1 Computadora anfitriona
Permítanme mencionar primero la computadora host.
La computadora host generalmente no es un programa enorme. Se utiliza principalmente para:
- Proporciona una interfaz fácil de usar;
- Comunicarse con la computadora inferior para procesar los datos recopilados y presentarlos en la interfaz;
- Almacene algunos datos en la base de datos para informes, consultas y análisis estadísticos;
- Conéctese con sistemas de nivel superior (MES, ERP, etc.);
- También se puede combinar con algunas tecnologías profesionales (como visión, procesamiento de documentos, etc.) para ayudar a la producción.
Un programa tan pequeño para equipos especializados implica una amplia gama de tecnologías.
2.2 Singleton y sus aplicaciones
El propósito de un singleton es garantizar que una clase tenga solo una instancia en el programa y proporcionar un punto de acceso global para acceder a ella.
Obviamente, el diseño de un singleton permite que una clase tenga solo una instancia, y debe ser de fácil acceso desde el mundo exterior, para facilitar el control de la instancia y ahorrar recursos del sistema.
Por tanto, sus escenarios de aplicación suelen ser:
- Hay casos de creación de instancias frecuentes (es decir, novedades frecuentes) y luego destrucción;
- Crear objetos lleva demasiado tiempo o consume demasiados recursos;
- Objetos que acceden con frecuencia a recursos de E/S, como archivos o grupos de conexiones de bases de datos.
Creo que muchas personas usan singletons por primera vez no por problemas de rendimiento, sino simplemente porque quieren algo similar a una variable global en lenguaje C. Esperan que se pueda acceder a una instancia de una clase mediante código en diferentes páginas. En realidad, esta es la característica de proporcionar un punto de acceso global mencionada en el singleton.
Aquí hay una aplicación con la que todo el mundo está muy familiarizado: el Administrador de tareas de Windows. Se abre Ctrl + Shift + Esc y no importa cuántas veces lo presiones, solo aparecerá un administrador de tareas. En otras palabras, en el sistema Windows, el Administrador de tareas es el único.
Entonces, ¿por qué está diseñado de esta manera? ¿Qué pasaría si no estuviera diseñado de esta manera?
- Si aparecen varias ventanas del Administrador de tareas y el contenido que se muestra en estas ventanas es exactamente el mismo, todos los objetos abiertos estarán duplicados, lo que provocará un desperdicio de recursos del sistema y pérdida de memoria. En el uso real, no hay necesidad de que varias ventanas presenten el mismo contenido.
- Es aún peor si aparecen varias ventanas del Administrador de tareas con contenido inconsistente. Esto significa que existen múltiples estados de uso de aplicaciones, procesos, servicios y otra información en un momento determinado, entonces, ¿cuál es real? Obviamente esto es aún más indeseable.
Se puede ver que es muy importante asegurarse de que solo haya un administrador de tareas en el sistema.
2.3 Aplicación en la computadora host
En el desarrollo de la computadora host, a menudo se encontrarán situaciones similares. Aquí hay algunos ejemplos comunes:
2.3.1 Información de inicio de sesión del usuario
La computadora host a veces requiere funciones de permiso y algunas funciones de la página requieren permisos específicos para funcionar.
Es decir, la información del usuario obtenida en diferentes páginas es consistente. Para lograr este requisito, la información del usuario debe ser globalmente única. A menudo, cuando un usuario inicia sesión, la información del usuario que contiene varios permisos se carga en un singleton.
2.3.2 Archivo de configuración
Los programas de computadora host a menudo requieren algunos archivos de configuración de parámetros, como los relacionados con el equipo y los hábitos del usuario. Si no usa un singleton, debe crear un nuevo objeto cada vez y volver a leer el archivo de configuración, lo que afecta en gran medida el rendimiento. Si usa un singleton, solo necesita leerlo una vez al principio.
2.3.3 Grupo de conexiones de datos
¿Por qué agrupar?
Debido a que crear una nueva conexión lleva mucho tiempo, si se crea una nueva conexión cada vez que llega una nueva tarea, afectará seriamente el rendimiento. Por lo tanto, el enfoque general es mantener un grupo de conexiones en una aplicación, de modo que cuando llegue una tarea, si hay una conexión inactiva, se pueda usar directamente, eliminando el costo de inicialización.
Aviso:
El singleton mencionado aquí es para crear un singleton para el grupo., en lugar de crear un singleton para una única conexión de base de datos.
Es incorrecto sellar un objeto de conexión de base de datos en un objeto singleton. Si crea un singleton para una única conexión de base de datos, cuando varias partes soliciten conexiones, solo podrá usar una conexión de base de datos. ¿No es una muerte terrible?
2.4 Reflexiones sobre un escenario de aplicación
Además de los usos generales anteriores, también intenté usar singletons para la necesidad de retener el estado al cambiar de página.
El escenario específico es el siguiente: hay varias páginas en una computadora host en modo MVVM. Espero que después de cambiar de página y luego volver a la página original (la página es la Página, que puede considerarse como una Vista), la pantalla mostrada El contenido seguirá siendo el mismo que antes. El contenido de la página puede entenderse como las propiedades, comandos, etc. en ViewModel.
Para cumplir con este requisito, los singleton se pueden utilizar de muchas maneras.
- Singleton de algunos objetos clave en ViewModel (generalmente el modelo agregado en ViewModel);
- Singleton ViewModel para que solo haya un ViewModel en el programa;
- Singleton toda la vista.
Camino 1
Si los objetos clave en ViewModel son singleton, ViewModel se recreará al volver a la página original y estos objetos singleton se cargarán en él.
Camino 2
Si crea un único modelo de vista completo, solo necesita vincular el DataContext de la vista al modelo de vista único.
Camino 3
Si toda la Vista es única, solo necesita navegar a la Vista única de destino para cambiar de página.
Entonces la pregunta es, ¿cuál es mejor?
Obviamente no hay respuesta a este tipo de preguntas, depende de escenarios más específicos.
Incluso puede agregar varias subpáginas en la clase de página de inicio sin utilizar un singleton y luego simplemente hacer clic para navegar a las subpáginas.
Ahora, volvamos al caso del uso de singletons,
si hay muchos modelos agregados en su modelo de vista y los modelos pueden usarse en otras páginas, entonces, obviamente, estos modelos deben ser singleton.
Si hay muchos elementos de estado independientes en su modelo de vista, solo se registra el estado de la página, que casi no tiene nada que ver con el modelo. También es razonable hacer que todo el ViewModel sea singleton.
Si hay algunos objetos vinculados en su Vista, como el Lienzo, y dibuja algunas imágenes en el Lienzo, el Lienzo pertenece a la Vista. También es razonable hacer de View un singleton.
No hay una respuesta clara sobre qué método se utilizará al final. En la actualidad, solo podemos elegir un método aparentemente razonable basado en la situación real y probarlo mediante la práctica.
3. Resumen
Singleton es un patrón de diseño muy básico, recuerda que es paraAsegúrese de que una clase tenga solo una instancia en el programa y proporcione un punto de acceso global a ella.Eso es todo.
Escenarios de aplicación comunes, estado de usuario, archivos de configuración, grupos de conexiones de bases de datos, etc.
También se puede utilizar cuando se utiliza el mismo modelo en varias páginas. No hay necesidad de preocuparse demasiado por el uso de algunas escenas, siempre que se pueda lograr el efecto.