我是否需要在 Visual Studio 2017 ASP.NET Core MVC 中将异步添加到我的控制器操作

Question

我刚刚将我的 Visual Studio 2015 ASP.NET MVC Core 项目转换为 Visual Studio 2017...我在错误列表中收到以下信息性消息

消息 IDE1006 命名规则违规：缺少后缀：'Async'

此消息出现在我的控制器中，主要关注以下内容：

public async Task<IActionResult> Index()

这也适用于创建、删除、详细信息和编辑。这些消息显示为信息性并适用于我的项目中的 1,000 多个事件。看来我需要将 Index 更改为 IndexAsync 即。
更改自：

public async Task<IActionResult> Index()
public async Task<IActionResult> Create()
public async Task<IActionResult> Delete(int? id)
public async Task<IActionResult> Details(int? id)

改为：

public async Task<IActionResult> IndexAsync()
public async Task<IActionResult> CreateAsync()
public async Task<IActionResult> DeleteAsync(int? id)
public async Task<IActionResult> DetailsAysnc(int? id)

此时这似乎是可选的，因为我的项目将构建，这在 VS 2015 中不是问题。我不介意做这项工作，我需要确认在 Visual Studio 2017 ASP.NET Core 中更改它是正确的方法。

Answer 1

Microsoft 正在推动您使用 async 一词为您的异步方法添加后缀。为什么？ Visual Studio 2017 的release notes 提到了这个花絮。

异步方法的类似任务的返回类型：这引入了能力 从异步方法返回任何类似任务的类型。以前这些 返回类型被限制为Task<T> 和Task。

听起来，仅通过检查它们的返回类型，哪些方法是异步的就变得不那么明显了。给它们加上 async 后缀可能是个好主意。在 VS 提出这个“建议”之前，有一个 previous stack overflow question 就该公约进行辩论。来自 Microsoft 的 Stephen Toub 解决了这个问题，我引用了。

如果公共方法是任务返回并且本质上是异步的（如 与已知始终同步执行的方法相反 完成但由于某种原因仍然返回一个任务），它应该有 “异步”后缀。这就是指导方针。这里的主要目标是 命名是为了让消费者非常清楚 被调用的方法可能无法完成的功能 它的所有工作都是同步的；它当然也有助于案件 同步和异步同时公开功能的地方 方法，以便您需要名称差异来区分它们。如何 该方法实现其异步实现无关紧要 命名：是否使用 async/await 来获得编译器的帮助， 或者是否使用 System.Threading.Tasks 中的类型和方法 直接（例如TaskCompletionSource）并不重要，因为那 就消费者而言，不会影响方法的签名 方法有关。

当然，准则总有例外。最多 在命名的情况下值得注意的一个是整个 type 存在的理由是提供以异步为中心的功能，在 在这种情况下，在每个方法上都使用 Async 将是矫枉过正的，例如这 产生其他任务的任务本身的方法。

对于返回 void 的异步方法，不希望有 那些在公共表面区域的，因为来电者没有好的方法 知道异步工作何时完成。如果你必须暴露一个 但是，您可能会公开返回 void 的异步方法 希望有一个名称来传达异步工作正在 启动，如果有意义，您可以在此处使用“异步”后缀。 鉴于这种情况应该是多么罕见，我认为这确实是一个 逐案决定。

希望对你有帮助，史蒂夫

底线，它是信息性的。但随着 Microsoft 将返回类型扩展到 Task 之外，它开始看起来越来越像最佳实践。用你自己的判断。

Answer 2

我注意到对于 MVC 控制器类，除了将 Async 添加到方法名称之外，我还需要添加 [ActionName("MethodName")] 作为方法属性，其中“MethodName”最后没有 Async。如果我没有添加 ActionName 属性，代码会编译，但 URL 不会路由到方法，除非我也在 URL 中添加了 Async。我不想在我的 URL 中使用异步，所以我最终在各处添加了 ActionName 属性。似乎 MVC 路由引擎应该尝试找到 Async 方法，但事实并非如此。