我以这个问题为基础提出我的问题。
TL;DR: 如果不应该将同步代码包装在异步包装器中，那么如何处理长时间运行、线程阻塞的方法，这些方法实现了一个期望异步实现的接口方法？
假设我有一个应用程序，持续运行以处理工作队列。它是一个服务器端应用程序（大部分情况下无人值守运行），但它有一个UI客户端，可以根据业务流程要求提供更细粒度的对应用程序行为的控制：启动、停止、在执行过程中调整参数、获取进度等。
业务逻辑层中注入了服务依赖项。BLL为这些服务定义了一组接口。
我想保持客户端的响应性：允许UI客户端与正在运行的进程交互，同时我也希望线程能够高效利用，因为该进程需要可扩展性：根据队列中的工作可能会有任意数量的异步数据库或磁盘操作。因此，我使用async/await一路走来。
为此，我在服务接口中有一些明显设计鼓励async/await和支持取消的方法，因为它们接受CancellationToken，以"Async"命名，并返回Task。
我有一个数据存储库服务，执行CRUD操作以持久化我的领域实体。假设在目前，我使用的API并不原生支持异步。将来，我可能会用支持异步的API替换它，但目前，数据存储库服务执行大部分操作都是同步的，其中许多是长时间运行的操作（因为API在数据库IO上阻塞）。
现在，我明白返回
Task的方法可以同步运行。我的服务类中实现BLL接口的方法将像我解释的那样同步运行，但使用者（我的BLL、客户端等）将假设它们要么1：异步运行，要么2：同步运行很短的时间。方法不应该在async调用Task.Run内包装同步代码。我知道我可以在接口中定义同步和异步方法。在这种情况下，我不想这样做，因为我正在尝试使用"一路异步"语义，并且因为我不是编写供客户使用的API；如上所述，我不想以后从使用同步版本更改为使用异步版本来更改我的BLL代码。
以下是数据服务接口:
public interface IDataRepository
{
Task<IReadOnlyCollection<Widget>>
GetAllWidgetsAsync(CancellationToken cancellationToken);
}
并且它的实现方式是：
public sealed class DataRepository : IDataRepository
{
public Task<IReadOnlyCollection<Widget>> GetAllWidgetsAsync(
CancellationToken cancellationToken)
{
/******* The idea is that this will
/******* all be replaced hopefully soon by an ORM tool. */
var ret = new List<Widget>();
// use synchronous API to load records from DB
var ds = Api.GetSqlServerDataSet(
"SELECT ID, Name, Description FROM Widgets", DataResources.ConnectionString);
foreach (DataRow row in ds.Tables[0].Rows)
{
cancellationToken.ThrowIfCancellationRequested();
// build a widget for the row, add to return.
}
// simulate long-running CPU-bound operation.
DateTime start = DateTime.Now;
while (DateTime.Now.Subtract(start).TotalSeconds < 10) { }
return Task.FromResult((IReadOnlyCollection<Widget>) ret.AsReadOnly());
}
}
BLL：
public sealed class WorkRunner
{
private readonly IDataRepository _dataRepository;
public WorkRunner(IDataRepository dataRepository) => _dataRepository = dataRepository;
public async Task RunAsync(CancellationToken cancellationToken)
{
var allWidgets = await _dataRepository
.GetAllWidgetsAsync(cancellationToken).ConfigureAwait(false);
// I'm using Task.Run here because I want this on
// another thread even if the above runs synchronously.
await Task.Run(async () =>
{
while (true)
{
cancellationToken.ThrowIfCancellationRequested();
foreach (var widget in allWidgets) { /* do something */ }
await Task.Delay(2000, cancellationToken); // wait some arbitrary time.
}
}).ConfigureAwait(false);
}
}
展示和展示逻辑：
private async void HandleStartStopButtonClick(object sender, EventArgs e)
{
if (!_isRunning)
{
await DoStart();
}
else
{
DoStop();
}
}
private async Task DoStart()
{
_isRunning = true;
var runner = new WorkRunner(_dependencyContainer.Resolve<IDataRepository>());
_cancellationTokenSource = new CancellationTokenSource();
try
{
_startStopButton.Text = "Stop";
_resultsTextBox.Clear();
await runner.RunAsync(_cancellationTokenSource.Token);
// set results info in UI (invoking on UI thread).
}
catch (OperationCanceledException)
{
_resultsTextBox.Text = "Canceled early.";
}
catch (Exception ex)
{
_resultsTextBox.Text = ex.ToString();
}
finally
{
_startStopButton.Text = "Start";
}
}
private void DoStop()
{
_cancellationTokenSource.Cancel();
_isRunning = false;
}
所以问题是：如何处理长时间运行的、阻塞性方法，这些方法实现了一个期望异步实现的接口方法？这是否是打破“同步代码没有异步包装器”的规则的一个例子？