Lo consideraría un olor a arquitectura, ya que UpdateData probablemente debería pertenecer a una clase de 'servicio'.
Donde los datos son una manzana.
Donde AppleAdapter es servicio / clase de inteligencia de negocios.
Donde AppleService es una referencia Singleton a un AppleAdapter que existe fuera del método actual.
private static volatile AppleAdapter _appleService = null;
private static object _appleServiceLock = new object();
private AppleAdapter AppleService
{
get
{
if (_appleService == null)
{
lock (_appleServiceLock)
{
if (_appleService == null)
_appleService = new AppleAdapter();
}
}
return _appleService;
}
}
public SomeAppleRelatedMethod(Apple apple)
{
AppleService.UpdateData(apple);
}
No creo que lo que esté haciendo esté necesariamente mal, pero si SomeDataAdapter realmente representa algún tipo de servicio comercial sin estado, entonces un singleton sería la mejor práctica para ello.
¡Espero que ayude! El ejemplo proporcionado es una forma elegante de asegurar que no haya contención del _appleService si resulta que es nulo y se accede al mismo tiempo por dos o más subprocesos.
¿Sabes qué? Si SomeDataAdapter es un IDbDataAdapter de ADO (que es casi seguro que lo es), ¡ignora esta respuesta completa!
: P
No tengo permiso para agregar un comentario a la pregunta original, pero si puedes especificar dónde existe este código.
Si este código representa una implementación personalizada de un IDbDataAdapter, y UpdateData está creando una IDbConnection, IDbCommand, y conectándolo todo entre bastidores, entonces no lo consideraría un olor porque ahora estamos hablando de flujos y otras cosas que deben eliminarse cuando hayamos terminado de usarlos.