构造函数的作用与返回构造类型的方法非常相似。async方法不能返回任何类型，它必须是“触发并忘记”void或Task。

如果类型T的构造函数实际返回Task<T>，我认为这将非常令人困惑。

如果async构造函数的行为与async void方法相同，那就破坏了构造函数的意义。构造函数返回后，您应该得到一个完全初始化的对象。不是一个在将来某个未定义的点上将被正确初始化的对象。也就是说，如果你足够幸运，异步初始化没有失败。

所有这些都只是猜测。但在我看来，使用异步构造函数的可能性带来的麻烦比它的价值要多。

如果你真的想要async void方法的“发射并忘记”语义(如果可能的话应该避免)，你可以很容易地将所有代码封装在一个async void方法中，并从你的构造函数调用它，就像你在问题中提到的那样。

你可以创建一个包装器并注入一个表示构造函数的函子:

class AsyncConstruct<T>
    where T: class
{
    private readonly Task<T> m_construction;
    private T m_constructed;
    public AsyncConstruct(Func<T> createFunc)
    {
        m_constructed = null;
        m_construction = Task.Run(()=>createFunc());
    }

    public T Get()
    {
        if(m_constructed == null)
        {
            m_constructed = m_construction.Result;
        }
        return m_constructed;
    }
}

在这种特殊情况下，需要一个viewModel来启动任务，并在任务完成时通知视图。一个“async属性”，而不是一个“async构造函数”。

我刚刚发布了AsyncMVVM，它正好解决了这个问题(以及其他问题)。如果你使用它，你的ViewModel将变成:

public class ViewModel : AsyncBindableBase
{
    public ObservableCollection<TData> Data
    {
        get { return Property.Get(GetDataAsync); }
    }

    private Task<ObservableCollection<TData>> GetDataAsync()
    {
        //Get the data asynchronously
    }
}

奇怪的是，它支持Silverlight。：）

我不熟悉async关键字(这是针对Silverlight还是Visual Studio测试版的新功能?)，但我想我可以告诉你为什么不能这样做。

如果我这样做:

var o = new MyObject();
MessageBox(o.SomeProperty.ToString());

在运行下一行代码之前，O可能无法完成初始化。在构造函数完成之前，不能分配对象的实例化，并且使构造函数异步不会改变这一点，那么重点是什么呢?然而，你可以从你的构造函数调用一个异步方法，然后你的构造函数就可以完成，你就可以在async方法仍然在做它需要做的事情来设置你的对象的时候得到你的实例化。

其中一些答案涉及创造一种新的公共方法。不这样做，使用Lazy<T>类:

public class ViewModel
{
    private Lazy<ObservableCollection<TData>> Data;

    async public ViewModel()
    {
        Data = new Lazy<ObservableCollection<TData>>(GetDataTask);
    }

    public ObservableCollection<TData> GetDataTask()
    {
        Task<ObservableCollection<TData>> task;

        //Create a task which represents getting the data
        return task.GetAwaiter().GetResult();
    }
}

要使用Data，请使用Data. value。

我只是想知道为什么我们不能直接从构造函数中调用await。

我相信简短的答案很简单:因为. net团队还没有编写这个特性。

我相信使用正确的语法可以实现这一点，而且不应该太令人困惑或容易出错。我认为Stephen Cleary的博客文章和其他几个答案已经含蓄地指出，没有根本的理由反对它，而且更重要的是——用变通方法解决了这个不足。这些相对简单的变通方法的存在可能是这个特性(还)没有实现的原因之一。