IoC 服务的抽象类还是接口？

我目前正在使用 IoC 在项目中提供存储库的具体实现。我读过的所有示例都使用接口作为服务的定义。但是，在阅读了 Microsoft 的建议后，建议更喜欢抽象类而不是接口 http://msdn.microsoft.com/en-us/library/ms229013.aspx.

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

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

如果常见任务是加载活动产品，那么我需要执行以下操作：

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

Where 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因此与持久层没有耦合。如果发现存在另一个经常执行的活动，则可以将其作为非破坏性更改添加到基类中，而这是使用接口无法完成的。

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

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

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

使用接口而不是抽象基类之间的一个大问题是接口不能很好地进行版本控制 http://haacked.com/archive/2008/02/21/versioning-issues-with-abstract-base-classes-and-interfaces.aspx.

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