IoC服务的抽象类或接口？

Question

我目前正在使用IoC在项目中提供存储库的具体实现.我读过的所有示例都使用接口作为服务的定义.但是,阅读Microsoft的建议后,建议您更喜欢接口上的抽象类.

我发现这与模板模式相结合有用,可以减少重复.例如,给一个Product具有属性的类IsActive我可以使用存储库的接口,例如:

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();

加载产品信息的所有实现都在派生的contrete类中,ProductRepository因此不存在与持久层的耦合.如果发现存在另一个通常执行的活动,则可以将其添加到基类中,作为使用接口无法完成的非破坏性更改.

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

我使用Castle Windsor作为IoC控制器和.Net framework 3.5.

Answer 1

我不认为这个问题取决于IoC; 大多数这些框架并不关心您使用哪种框架.

在抽象基类上使用接口之间的一个大问题是接口无法很好地进行版本控制.

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