llamadas asincrónicas dentro de obtener acceso - ¿es una buena práctica?

Question

Tengo una ventana que muestra la información del cliente. cuando se carga la ventana, llamo al método LoadCustomer() desde el constructor que carga la información del cliente de la base de datos de forma asincrónica, lo que establece la propiedad CurrentCustomer. y luego la interfaz de usuario se actualiza porque está vinculada al CurrentCustomer.

private void LoadCustomer(Guid customerID) 
{   
    var customerContext = new CustomerContext(); 

    var customerQuery = customerContext.GetCustomersQuery() 
             .Where(e => e.CustomerID == customerID); 

    customerContext.Load(customerQuery, 
     loadOperation => 
     { 
     CurrentCustomer = loadOperation.Entities.SingleOrDefault(); 
     }, null); 
} 

El programador senior me ha dicho que es mejor poner esta lógica dentro de acceso get de CurrentCustomer, porque entonces

• las llamadas a la base de datos utilizarán la carga diferida, y
• la refactorización lo haría ser más fácil.

¿Es una buena práctica colocar las llamadas de la base de datos asincrónicas dentro del acceso de acceso de la propiedad?

Answer 1

En general, no lo es.

lo general, si algo iba a conseguir implica hacer algo más caro, así, se debe utilizar un método getter completo sólo para este propósito:

public object GetSomething() { } 

// accessing code 
var value = obj.GetSomething(); 

Esto significa que cada vez que algo no está libre ... Compare con:

var value = obj.Something; 

Esto se parece más a una asignación de valor normal ocultando la peligrosa llamada asincrónica pasando detrás de la escena que, en mi opinión es una mala idea.

Pero como con todo lo demás ... depende en otras partes de toda la arquitectura también.

Si todo el propósito del objeto es abstraer muchas llamadas asincrónicas usando propiedad (como en el caso de las entidades Linq2Sql o Entity Framework), está bien porque debe tener en cuenta que se trata de llamadas que no están (o cerca de) libres del contexto del código.

...

Depende del contexto del código. Si cada vez que está accediendo a esta propiedad, está seguro de que se le recordará la costosa llamada, entonces creo que está bien. Pero si ese no es el caso, entonces debe hacerlo más explícito convirtiéndolo en un método completo en lugar de una propiedad.

Answer 2

Está en lo cierto acerca de la carga lenta en el descriptor de acceso, ya que la llamada asincrónica no se realizará en la creación del objeto. Solo se realizará cuando se llame al descriptor de acceso.

También prevé no dejarlo en el elemento de acceso a la propiedad, sino refaccionarlo en otro lugar. Es más fácil refactorizar cuando la llamada ya está aislada en el acceso.

Sin embargo, no es una buena idea dejar la llamada asincrónica en el accesorio, pero no parece que esté esperando que permanezca allí.

Answer 3

Parece que su desarrollador principal se ha perdido la naturaleza asincrónica del código.La única forma de mover el código al captador de una propiedad sería bloquear el hilo de llamada hasta que se complete la operación asíncrona y haya un valor que devolver. Esta sería una propiedad muy mal educada.