¿Hay alguna razón para que un grupo de objetos no se trate como un singleton?

Question

No me refiero necesariamente a que se implemente utilizando el patrón singleton, sino que solo tiene y usa una instancia de un grupo. No me gusta la idea de tener solo un grupo (o uno por tipo agrupado). Sin embargo, no puedo pensar en ninguna situación concreta en la que haya una ventaja para varias agrupaciones para los tipos mutables, al menos en ninguna parte donde una sola agrupación pueda funcionar igual de bien.

¿Qué ventajas hay para tener varias agrupaciones en una agrupación singleton?

Answer 1

¿Qué ventajas hay en tener piscinas múltiples sobre una piscina individual?

que supone la mayoría de las piscinas de objetos que utilizamos, como el ThreadPool, se implementan como simple por simplicidad: en la que, los diseñadores de estas piscinas no vieron un propósito en multiinstancias piscinas tampoco.

Sin embargo, hay un puñado de lugares donde realmente tenemos varios grupos: grupos de aplicaciones IIS y grupos de conexiones de bases de datos.

piscinas aplicación

En IIS, puede configurar varios grupos de aplicaciones, por lo que las aplicaciones web relacionados todos corren en su propia piscina. Hay un par de ventajas a este diseño, y las ventajas que se pueden generalizar a las implementaciones de la piscina exterior de IIS:

• piscinas múltiple objeto permitir un cierto grado de aislamiento, por lo que un error en una piscina no debería tener un impacto en objetos en otras piscinas.

• Cada grupo puede ejecutarse bajo un usuario diferente, lo que le brinda diferentes niveles de seguridad en función de su grupo de aplicaciones.

• Cada grupo puede tener un controlador diferente para errores.

• Cada grupo puede ejecutarse con una versión diferente de .NET framework.

• Cada grupo puede tener su propio tiempo de espera de HTTP.

piscinas de conexión

En SQL Server, varias llamadas a una conexión de base de datos puesta en común su uso para evitar la sobrecarga de crear una nueva conexión de base de datos en cada consulta, sin embargo, SQL Server creates a new pool per connection string. Me imagino que la razón de este diseño es el siguiente:

• Cada grupo tiene una conexión a una instancia de base de datos específica. Si hubiera solo un grupo que contenga todas las conexiones, entonces necesitaría buscar a través de todas las conexiones hasta que encuentre la conexión que coincida con la cadena de conexión que ha solicitado. Como hay varios grupos por cadena de conexión, es más fácil extraer la primera conexión disponible de ese grupo en particular sin buscar otras conexiones.

• En otras palabras, sospecho que SQL Server usa varios grupos de conexiones como una optimización para obtener rápidamente una conexión de base de datos.

• También puedo imaginar que todas esas conexiones probablemente compartan algunos recursos específicos para su grupo de conexiones, lo que puede no ser posible con un grupo único. Por ejemplo, puede especificar el tamaño máximo de la agrupación de conexiones por cadena de conexión; es posible que no pueda controlar el número de conexiones simultáneas a una base de datos particular utilizando un diseño de grupo único.

cómo diseñar una piscina

Realmente no se puede elegir si desea tener múltiples piscinas o un solo grupo sin mirar lo que realmente necesita de su diseño.

Si tiene un grupo de objetos muy simple, es posible que pueda salirse con un diseño singleton. Si realmente necesita flexibilidad adicional, personalización o tal vez tiene una configuración realmente única, como un conjunto de objetos distribuidos en múltiples procesos o máquinas, definitivamente se beneficiaría de un diseño n-gleton.

Answer 2

Sí, definitivamente existen posibles razones para tener varios grupos de objetos; en particular, es posible que desee permitir que un grupo sea elegible para la recolección de basura (o liberarlo manualmente, etc.) mientras mantiene otros.

Por ejemplo, considere un grupo de objetos para cadenas. Eso puede ser muy útil en el contexto de XML: si está analizando varios documentos XML del mismo esquema, posiblemente quiera agrupar las cadenas utilizadas para los nombres de los elementos y los atributos. Sin embargo, una vez que haya terminado esa parte del procesamiento, es posible que nunca vuelva a utilizar esos nombres, de modo que al pasar a un conjunto diferente de documentos, es posible que desee utilizar un grupo diferente. Puede terminar haciendo ambas tareas a la vez, en cuyo caso es útil tener ambas agrupaciones disponibles simultáneamente.

O considere los grupos de subprocesos: considero una desventaja de la implementación del grupo de subprocesos .NET que básicamente hay solo un grupo de subprocesos del sistema. Me gusta la idea de poder tener varios grupos de subprocesos en un servidor: algunos subprocesos para trabajos por lotes de baja prioridad, algunos para solicitudes "normales" y algunos subprocesos de alta prioridad para trabajos como el monitoreo de estado.

Answer 3

Si implementa cuidadosamente un patrón de singleton, puede cambiar de opinión más adelante. Simplemente encapsula el singleton de tu clase detrás de un método de fábrica. Si todo lo usa, puede permitir que tenga varias instancias más adelante, cuando tenga una buena razón.

public class MyClass 
{ 
    public static MyClass GetInstance() 
    { 
      return singleton_ ?? (singleton = new MyClass()); 
    } 
}