design-patterns - IoC 服务的抽象类或接口(interface)？

Question

我目前正在使用 IoC 在项目中提供存储库的具体实现。我读过的所有示例都使用接口(interface)作为服务的定义。但是，在阅读了 Microsoft 的建议后，建议使用 prefer abstract classes over interfaces .

我发现这与模板模式结合使用可以减少重复。例如给出 Product具有属性的类 IsActive我可以使用存储库的接口(interface)，例如:

interface IProductRepository
{
    IEnumerable<Product> Load();
}

如果一个常见的任务是加载事件产品，那么我需要做:

IEnumerable<Product> activeProducts = repository.Load().Where(x => x.IsActive);

在哪里 repository是一个具体的实现。如果我使用了一个抽象类，例如:

abstract class ProductRepository
{
    protected abstract IEnumerable<Product> LoadCore();

    public IEnumerable<Product> Load()
    {
        return LoadCore().Where(x => x.IsActive);
    }
}

然后我可以使用加载事件产品

IEnumerable<Product> activeProducts = repository.Load();

加载产品信息的所有实现都在派生 ProductRepository 的具体类中。所以没有与持久层的耦合。如果发现有另一个通常执行的事件，则可以将其添加到基类中，作为无法使用接口(interface)完成的非破坏性更改。

使用接口(interface)而不是抽象类有什么好处吗？我会遇到使用抽象类的哪些潜在缺点？

我使用 CaSTLe Windsor 作为 IoC Controller 和 .Net 框架 3.5。

Answer 1

我不认为这个问题取决于 IoC。这些框架中的大多数都不关心您使用哪个。

在抽象基类上使用接口(interface)之间的大问题是 interfaces cannot be versioned well .

因此，抽象基类通常是更好的选择。我认为使用抽象基类没有任何缺点，除了得到诸如“为什么我不能创建这种类型的实例？”之类的支持问题。