¿Cómo llamar a un método asíncrono desde un getter o setter?

¿Cuál sería la forma más elegante de llamar a un método asíncrono desde un getter o setter en C #?

Aquí hay un pseudocódigo para ayudar a explicarme.

async Task<IEnumerable> MyAsyncMethod()
{
    return await DoSomethingAsync();
}

public IEnumerable MyList
{
    get
    {
         //call MyAsyncMethod() here
    }
}

No hay ninguna razón técnica para que las asyncpropiedades no estén permitidas en C #. Fue una decisión de diseño intencional, porque las "propiedades asincrónicas" son un oxímoron.

Las propiedades deben devolver los valores actuales; no deberían estar iniciando operaciones en segundo plano.

Por lo general, cuando alguien quiere una "propiedad asincrónica", lo que realmente quiere es uno de estos:

1. Un método asincrónico que devuelve un valor. En este caso, cambie la propiedad a un asyncmétodo.
2. Un valor que se puede usar en el enlace de datos pero que se debe calcular / recuperar de forma asincrónica. En este caso, use un asyncmétodo de fábrica para el objeto que lo contiene o use un async InitAsync()método. El valor vinculado a los datos será default(T)hasta que se calcule / recupere el valor.
3. Un valor costoso de crear, pero que debe almacenarse en caché para su uso futuro. En este caso, utilícelo AsyncLazy desde mi blog o biblioteca AsyncEx . Esto le dará una awaitpropiedad capaz.

Actualización: cubro las propiedades asincrónicas en una de mis publicaciones de blog recientes "async OOP".

No puede llamarlo de forma asincrónica, ya que no hay soporte de propiedad asincrónica, solo métodos asincrónicos. Como tal, hay dos opciones, ambas aprovechando el hecho de que los métodos asincrónicos en el CTP son realmente solo un método que devuelve Task<T>o Task:

// Make the property return a Task<T>
public Task<IEnumerable> MyList
{
    get
    {
         // Just call the method
         return MyAsyncMethod();
    }
}

O:

// Make the property blocking
public IEnumerable MyList
{
    get
    {
         // Block via .Result
         return MyAsyncMethod().Result;
    }
}

Realmente necesitaba que la llamada se originara en el método get, debido a mi arquitectura desacoplada. Entonces se me ocurrió la siguiente implementación.

Uso: El título está en un ViewModel o un objeto que podría declarar estáticamente como un recurso de página. Vincúlelo y el valor se completará sin bloquear la interfaz de usuario, cuando getTitle () regrese.

string _Title;
public string Title
{
    get
    {
        if (_Title == null)
        {   
            Deployment.Current.Dispatcher.InvokeAsync(async () => { Title = await getTitle(); });
        }
        return _Title;
    }
    set
    {
        if (value != _Title)
        {
            _Title = value;
            RaisePropertyChanged("Title");
        }
    }
}

Creo que podemos esperar que el valor devuelva primero nulo y luego obtener el valor real, por lo que en el caso de Pure MVVM (proyecto PCL, por ejemplo), creo que la siguiente es la solución más elegante:

private IEnumerable myList;
public IEnumerable MyList
{
  get
    { 
      if(myList == null)
         InitializeMyList();
      return myList;
     }
  set
     {
        myList = value;
        NotifyPropertyChanged();
     }
}

private async void InitializeMyList()
{
   MyList = await AzureService.GetMyList();
}

Puedes usar Taskasí:

public int SelectedTab
        {
            get => selected_tab;
            set
            {
                selected_tab = value;

                new Task(async () =>
                {
                    await newTab.ScaleTo(0.8);
                }).Start();
            }
        }

Pensé .GetAwaiter (). GetResult () era exactamente la solución a este problema, ¿no? p.ej:

string _Title;
public string Title
{
    get
    {
        if (_Title == null)
        {   
            _Title = getTitle().GetAwaiter().GetResult();
        }
        return _Title;
    }
    set
    {
        if (value != _Title)
        {
            _Title = value;
            RaisePropertyChanged("Title");
        }
    }
}

Como su "propiedad asíncrona" está en un modelo de vista, puede usar AsyncMVVM :

class MyViewModel : AsyncBindableBase
{
    public string Title
    {
        get
        {
            return Property.Get(GetTitleAsync);
        }
    }

    private async Task<string> GetTitleAsync()
    {
        //...
    }
}

Se encargará del contexto de sincronización y la notificación de cambio de propiedad.

Nigromancia
En .NET Core / NetStandard2, puede usar en Nito.AsyncEx.AsyncContext.Runlugar de System.Windows.Threading.Dispatcher.InvokeAsync:

class AsyncPropertyTest
{

    private static async System.Threading.Tasks.Task<int> GetInt(string text)
    {
        await System.Threading.Tasks.Task.Delay(2000);
        System.Threading.Thread.Sleep(2000);
        return int.Parse(text);
    }


    public static int MyProperty
    {
        get
        {
            int x = 0;

            // /programming/6602244/how-to-call-an-async-method-from-a-getter-or-setter
            // /programming/41748335/net-dispatcher-for-net-core
            // https://github.com/StephenCleary/AsyncEx
            Nito.AsyncEx.AsyncContext.Run(async delegate ()
            {
                x = await GetInt("123");
            });

            return x;
        }
    }


    public static void Test()
    {
        System.Console.WriteLine(System.DateTime.Now.ToString("dd.MM.yyyy HH:mm:ss.fff"));
        System.Console.WriteLine(MyProperty);
        System.Console.WriteLine(System.DateTime.Now.ToString("dd.MM.yyyy HH:mm:ss.fff"));
    }


}

Si simplemente elige System.Threading.Tasks.Task.Runo System.Threading.Tasks.Task<int>.Run, entonces no funcionaría.

Creo que mi ejemplo a continuación puede seguir el enfoque de @ Stephen-Cleary, pero quería dar un ejemplo codificado. Esto es para usar en un contexto de enlace de datos, por ejemplo Xamarin.

El constructor de la clase, o el configurador de otra propiedad de la que depende, puede llamar a un vacío asíncrono que llenará la propiedad al completar la tarea sin la necesidad de esperar o bloquear. Cuando finalmente obtenga un valor, actualizará su interfaz de usuario a través del mecanismo NotifyPropertyChanged.

No estoy seguro de los efectos secundarios de llamar a un vacío de Aysnc desde un constructor. Tal vez un comentarista elaborará el manejo de errores, etc.

class MainPageViewModel : INotifyPropertyChanged
{
    IEnumerable myList;

    public event PropertyChangedEventHandler PropertyChanged;

    public MainPageViewModel()
    {

        MyAsyncMethod()

    }

    public IEnumerable MyList
    {
        set
        {
            if (myList != value)
            {
                myList = value;

                if (PropertyChanged != null)
                {
                    PropertyChanged(this, new PropertyChangedEventArgs("MyList"));
                }
            }
        }
        get
        {
            return myList;
        }
    }

    async void MyAsyncMethod()
    {
        MyList = await DoSomethingAsync();
    }


}

Cuando me encontré con este problema, intentar ejecutar una sincronía de método asíncrono desde un instalador o un constructor me metió en un punto muerto en el hilo de la interfaz de usuario, y el uso de un controlador de eventos requirió demasiados cambios en el diseño general.
La solución era, como suele ser, simplemente escribir explícitamente lo que quería que sucediera implícitamente, que era que otro hilo manejara la operación y que el hilo principal esperara a que terminara:

string someValue=null;
var t = new Thread(() =>someValue = SomeAsyncMethod().Result);
t.Start();
t.Join();

Se podría argumentar que abusé del marco, pero funciona.

Reviso todas las respuestas pero todas tienen un problema de rendimiento.

por ejemplo en:

string _Title;
public string Title
{
    get
    {
        if (_Title == null)
        {   
            Deployment.Current.Dispatcher.InvokeAsync(async () => { Title = await getTitle(); });
        }
        return _Title;
    }
    set
    {
        if (value != _Title)
        {
            _Title = value;
            RaisePropertyChanged("Title");
        }
    }
}

Deployment.Current.Dispatcher.InvokeAsync (async () => {Title = await getTitle ();});

use el despachador que no es una buena respuesta.

pero hay una solución simple, solo hazlo:

string _Title;
    public string Title
    {
        get
        {
            if (_Title == null)
            {   
                Task.Run(()=> 
                {
                    _Title = getTitle();
                    RaisePropertyChanged("Title");
                });        
                return;
            }
            return _Title;
        }
        set
        {
            if (value != _Title)
            {
                _Title = value;
                RaisePropertyChanged("Title");
            }
        }
    }

Puedes cambiar la proactividad a Task<IEnumerable>

y hacer algo como:

get
{
    Task<IEnumerable>.Run(async()=>{
       return await getMyList();
    });
}

y úsalo como espera MyList;