抽象类中的同步或异步方法 [英] Sync or Async Methods in Abstract Class

问题描述

我考虑使用以下abstract class作为数据库迁移的基础:

I think about using the following abstract class as a base for database migrations:

using System.Threading.Tasks;

public abstract class MigrationBase
{
    public abstract string Name { get; }
    public abstract string Description { get; }
    public abstract int FromVersion { get; }
    public abstract int ToVersion { get; }
    public abstract void Apply();
    public abstract Task ApplyAsync();
}

现在，根据要为其编写具体迁移的底层数据库系统，实现void Apply或Task ApplyAsync方法可能更有意义.我看到以下选项:

Now, depending on the underlaying database system a concrete migration will be written for, it may make more sense to implement the void Apply or the Task ApplyAsync method. I see the following options:

1. 如果我决定仅使用这两种抽象方法之一，则会在
2. 如果我决定同时使用两种抽象方法，那么只要数据库系统不能同时提供两种方法，就会迫使他做错事.
3. 拥有MigrationBase，SyncMigrationBase和AsyncMigrationBase并在各处使用类型转换对我来说似乎并不合理.
4. 我目前缺少更好的选择吗?

1. If I decide just having one of both abstract methods, I force the developer implementing the concrete migration to do it wrong either in the one or the other way "in 50% of the cases".
2. If I decide having both abstract methods, I force him doing it wrong whenever the database system doesn't offer both possibilities.
3. Having a MigrationBase, SyncMigrationBase and AsyncMigrationBase and using typecasts everywhere doesn't seem reasonable to me.
4. Is there a better option I'm currently missing?

现在您可能会说我可以选择第二个选项，因为ADO.Net提供了同步和异步方法，并且在大多数情况下 数据库适配器将提供这两种变体.如果您在不考虑ADO.Net的情况下看更一般的问题，是否有更好的解决方案?
如果选择选项二，是否应该在考虑Stephen Toub撰写的内容的同时提供与Microsoft对System.IO.Stream.ReadAsync所做的类似的Task ApplyAsync的预实现版本?如果是，我还要注意什么?

Now you might say I could just choose option two because ADO.Net offers sync and async methods and in most cases the database adapters will offer both variants. Is there a better solution if you look at the more general problem without ADO.Net in mind?
If I chose option two, should I provide a preimplemented version of the Task ApplyAsync similar to what Microsoft did with System.IO.Stream.ReadAsync while considering what Stephen Toub has written? If yes, what else should I pay attention to?

推荐答案

单独使用ApplyAsync，然后删除其他方法.

Use ApplyAsync alone, and delete the other method.

如果我决定只使用这两种抽象方法之一，我将迫使实施具体移植的开发人员以一种或另一种方式做错事

If I decide just having one of both abstract methods, I force the developer implementing the concrete migration to do it wrong either in the one or the other way

如果用户需要从接口或抽象类中实现async方法，但是他必须同步执行所有操作，则用同步方法代替返回Task的async方法绝对没有问题，会返回根据结果构造的已完成任务.

If the user needs to implement an async method from an interface or an abstract class, but he must do everything synchronously, there is absolutely no problem substituting an async method returning a Task with a synchronous method, which returns a completed task constructed from result.

另一方面，您的代码总是像执行异步操作一样执行调用.

Your code, on the other hand, always performs calls as if they were asynchronous.

如果我决定同时拥有这两种抽象方法，那么只要数据库系统无法同时提供这两种可能性，就会迫使他做错事情.

If I decide having both abstract methods, I force him doing it wrong whenever the database system doesn't offer both possibilities.

是的，公开这两种方法是更糟糕的选择.

That's right, exposing both methods is a worse alternative.

拥有MigrationBase，SyncMigrationBase和AsyncMigrationBase并在各处使用类型转换对我来说似乎并不合理.

Having a MigrationBase, SyncMigrationBase and AsyncMigrationBase and using typecasts everywhere doesn't seem reasonable to me.

我认为您是对的，将可以折叠"的子类添加到基类中看起来确实比所需的工作多.

I think you are right, adding a subclass for what can be "folded" into the base class does look like more effort than is necessary.

这篇关于抽象类中的同步或异步方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！