Al diseñar una clase de servicio ¿debería ser singleton en java? En general, DAO se hace de forma individual, por lo que la clase de servicio de llamada también debe ser singleton.¿Debería una clase de servicio ser singleton en java?
Los singletons son malos, si los desarrolla. Si está utilizando inyección de dependencia, deje que el contenedor DI maneje la naturaleza singleton de su objeto de Servicio. Si no está usando inyección de dependencia, use un método estático en lugar de un singleton.
ejemplo clásico de mala:
public class HootUtility // singleton because developer was a goofball.
{
...
public void blammy(...) { ... }
public HootUtility getInstance() { ... }
}
... somewhere in the code.
HootUtility.getInstance().blammy(...); // This is silly.
mejor aplicación de las anteriores:
public class HootUtility // Not a singleton because I am not a ______. (fill in the blank as you see fit)
{
// You can limit instantiation but never prevent instantiation.
// google "java reflection" for details.
private HootUtility()
{
throw new UnsuppotedOperationException();
}
public static void blammy(...) { ... }
}
... somewhere in the code.
HootUtility.blammy(...);
Si usted tiene una interfaz de servicio que tiene una aplicación concreta, utilice un marco de inyección de dependencias para inyectar la implementación (Los marcos DI incluyen: spring y guice).
Editar: Si estuviera usando la primavera, elegiría el alcance singleton (el valor predeterminado).
En mi humilde opinión, los servicios no deberían mantener el estado y, por lo tanto, deben hacerse de forma única.
Ahora si lo haces singleton estamos alcanzando el rendimiento en caso de que la aplicación requiera una solicitud, es decir, hay un gran número de hits para la clase de servicio – Jyotirup
@Jyotirup El uso de un singleton correctamente no afectará el rendimiento (si algo lo mejora)) –
@Peter Hacerlo individualmente tendrá el efecto de que solo hay una instancia de esta clase para atender todas mis solicitudes. Así que ahora si tengo 10 solicitudes para la clase de servicio, las solicitudes se atenderán secuencialmente, por lo que habrá un retraso en el servicio ... Rendimiento alcanzado si amplío el número de solicitud – Jyotirup
Sin
En realidad, yo creo que no debe preocuparse por ello mientras que el diseño. Como @DwB mencionado DI marco debe hacer este trabajo. Además creo que no alcance ("prototipo") debe ser predeterminado y no veo nada malo si alguien lo creará por sí mismo. También ese problema se puede simplificar mediante la modularización y la separación de la interfaz de servicio y la implementación, como se dice en las mejores prácticas.
es un nuevo objeto de clase de servicio por solicitud ¿un mal enfoque? – Jyotirup
@Jyotirup No lo creo. Si están libres de estado, puede cambiar y está usando DI correctamente, puede cambiarlo fácilmente cuando lo desee. –
Diría que sería un mal enfoque del prototipo. Piensa si estás haciendo miles de solicitudes en tu aplicación web, o incluso cientos. Son cientos de instancias de una clase inicializada. Conceptualmente, si la creación de la clase y sus dependencias (por ejemplo, prototipos de dao con conexiones de db) es lo suficientemente cara, los servicios de creación de prototipos podrían llevar a una agitación más rápida, especialmente en el caso de un DDoS. Los servicios de Singletonned con un marco de DI como Spring @Autowired reducirían la asignación innecesaria de recursos – user3466773
Interesante acerca de lanzar una excepción en el constructor. Personalmente, simplemente lo dejé en blanco. ¿Lo haces realmente en tu código de producción? –
Si uso Spring DI, ¿el alcance debería ser "Singleton" o "Prototype"? – Jyotirup
En general estoy de acuerdo con usted. Sin embargo, la opción # 1 es una solución razonable si el objeto (singleton) tiene que mantener el estado interno. – home