我是否需要在Visual Studio 2017 ASP.NET Core MVC中将异步添加到我的控制器操作中 [英] Do I need to add Async to my Controller Actions in Visual Studio 2017 ASP.NET Core MVC

查看:60
本文介绍了我是否需要在Visual Studio 2017 ASP.NET Core MVC中将异步添加到我的控制器操作中的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚将我的Visual Studio 2015 ASP.NET MVC Core项目转换为Visual Studio 2017 ...并且在错误列表中得到了以下参考消息

I just converted my Visual Studio 2015 ASP.NET MVC Core project to Visual Studio 2017...and I get the following Informational messages in my Error List

消息IDE1006违反命名规则:缺少后缀:异步"

Message IDE1006 Naming rule violation: Missing suffix: 'Async'

此消息出现在我的控制器中,该控制器关注以下内容:

This message occurs in my Controllers that focus on the following:

public async Task<IActionResult> Index()

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

This also applies to Create, Delete, Details and Edit. The messages show as Informational and applies to over 1,000 occurences in my project. It appears that I need to change Index to IndexAsync ie.
Change from:

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中进行更改是正确的方法.

This appears to be optional at this time as my project will Build and it's not an issue in VS 2015. I don't mind doing the work,I need confirmation that changing this in Visual Studio 2017 ASP.NET Core is the correct approach.

推荐答案

Microsoft朝用async一词添加异步方法的方向对您进行了轻描淡写.为什么?Visual Studio 2017的发行说明提到了这一小窍门./p>

Microsoft is nudging you in the direction of suffixing your your asynchronous methods with the word async. Why? The release notes for Visual Studio 2017 mention this tidbit.

异步方法的类似于任务的返回类型:这引入了功能从异步方法返回任何类似任务的类型.以前这些返回类型仅限于 Task< T> Task .

听起来像哪种方法是异步的,仅通过检查它们的返回类型将变得不太明显.给它们加上后缀可能是一个好主意.在VS提出此建议"之前,有一个

Sounds like it's going to become less obvious which methods are asynchronous just from examining their return types. Suffixing them with async may be a good idea. Before VS was making this "suggestion" there was a previous stack overflow question debating the convention. Stephen Toub from Microsoft addressed it, and I quote.

如果公共方法是Task-returning并且本质上是异步的(如与已知总是同步执行的方法相反完成但由于某种原因仍返回任务),它应该具有一个异步"后缀.那就是指导方针.这里的主要目标命名是为了使它对消费者非常明显被调用的方法可能无法完成的功能其所有工作同步进行;当然也可以帮助解决这个问题同步和异步都公开了功能这样,您就需要一个名称差异来区分它们.如何该方法实现其异步实现对命名:是否使用async/await来获得编译器的帮助,或者是否使用System.Threading.Tasks中的类型和方法直接(例如TaskCompletionSource)并不重要,因为不会影响该方法的签名,甚至不会影响该方法的使用者有关方法.

If a public method is Task-returning and is asynchronous in nature (as opposed to a method that is known to always execute synchronously to completion but still returns a Task for some reason), it should have an "Async" suffix. That’s the guideline. The primary goal here with the naming is to make it very obvious to a consumer of the functionality that the method being invoked will likely not complete all of its work synchronously; it of course also helps with the case where functionality is exposed with both synchronous and asynchronous methods such that you need a name difference to distinguish them. How the method achieves its asynchronous implementation is immaterial to the naming: whether async/await is used to garner the compiler’s help, or whether types and methods from System.Threading.Tasks are used directly (e.g. TaskCompletionSource) doesn’t really matter, as that doesn’t affect the method’s signature as far as a consumer of the method is concerned.

当然,指南总是有例外.最多在命名的情况下,一个值得注意的情况是类型的存在理由是要提供异步功能,在每种方法上都具有Async的情况将是过大的,例如这Task本身产生其他任务的方法.

Of course, there are always exceptions to a guideline. The most notable one in the case of naming would be cases where an entire type’s raison d’etre is to provide async-focused functionality, in which case having Async on every method would be overkill, e.g. the methods on Task itself that produce other Tasks.

对于返回空值的异步方法,不希望具有那些在公共区域内的人,因为呼叫者没有好的方法知道异步工作何时完成.如果您必须公开但是,您可以公开地返回无效的异步方法想要有一个传达异步工作的名字启动后,您可以在此处使用异步"后缀.鉴于这种情况应该很少见,我认为这确实是一个视具体情况而定.

As for void-returning asynchronous methods, it’s not desirable to have those in public surface area, since the caller has no good way of knowing when the asynchronous work has completed. If you must expose a void-returning asynchronous method publicly, though, you likely do want to have a name that conveys that asynchronous work is being initiated, and you could use the "Async" suffix here if it made sense. Given how rare this case should be, I’d argue it’s really a case-by-case kind of decision.

我希望能有所帮助,史蒂夫

I hope that helps, Steve

底线,仅供参考.但是,随着Microsoft在Task之外扩展返回类型,它开始看起来越来越像最佳实践.使用您自己的判断.

Bottomline, it's informational. But as Microsoft has expanded the return types beyond Task, it it beggining to look more and more like best practice. Use your own judgement.

这篇关于我是否需要在Visual Studio 2017 ASP.NET Core MVC中将异步添加到我的控制器操作中的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆