关于C#：在存储库模式中使用接口优于抽象类的优势？

Advantage of using Interface over abstract class for repository pattern?

本问题已经有最佳答案，请猛点这里访问。

Possible Duplicate:
Interface vs Base class

通常会看到使用接口实现的存储库模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public interface IFooRepository
{
Foo GetFoo(int ID);
}

public class SQLFooRepository : IFooRepository
{
// Call DB and get a foo
public Foo GetFoo(int ID) {}
}

public class TestFooRepository : IFooRepository
{
// Get foo from in-memory store for testing
public Foo GetFoo(int ID) {}
}

但是您也可以使用抽象类来实现这一点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public abstract class FooRepositoryBase
{
public abstract Foo GetFoo(int ID);
}

public class SQLFooRepository : FooRepositoryBase
{
// Call DB and get a foo
public override Foo GetFoo(int ID); {}
}

public class TestFooRepository : FooRepositoryBase
{
// Get foo from in-memory store for testing
public override Foo GetFoo(int ID); {}
}

在存储库场景中，与抽象类相比，使用接口的具体优势是什么？

(也就是说，不要只是告诉我您可以实现多个接口，我已经知道了这一点——为什么要在存储库实现中这样做)

编辑以澄清-"msdn-在类和接口之间选择"等页面可以解释为"选择类而不是接口，除非有充分的理由不这样做"-在存储库模式的特定情况下，什么是好的理由

相关讨论

在这个实例中，与抽象类相比，使用接口的主要优点是接口是完全透明的：这是一个更大的问题，您无法访问继承的类的源。

但是，这种透明性允许您生成一个已知范围的单元测试：如果您测试一个接受接口作为参数的类(使用依赖项注入方法)，您就知道您正在用已知的数量测试该类；接口的测试实现将只包含您的测试代码。

同样，当测试存储库时，您知道您只测试存储库中的代码。这有助于限制测试中可能的变量/交互的数量。

就我个人而言，我倾向于有一个接口来保存纯"业务相关"的方法的签名，例如Foo GetFoo()、void DeleteFood(Foo foo)等。我还有一个通用抽象类，它保存受保护的方法，如T Get()或void Delete(T obj)。

我在抽象的Repository类中保护我的方法，这样外部世界就不知道水管工程(Repository看起来像object，而只知道通过接口的业务模型。

除了拥有水管厂的另一个优势外，我还有一个优势，例如，我有一个Delete方法(protected)可供任何存储库使用，但它不是公共的，因此我不必在存储库中强制实现它，因为它没有从我的数据源中删除某些内容的业务含义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

public abstract class Repository<T>
{
private IObjectSet objectSet;

protected void Add(T obj)
{
this.objectSet.AddObject(obj);
}

protected void Delete(T obj)
{
this.objectSet.DeleteObject(obj);
}

protected IEnumerable<T>(Expression<Func<T, bool>> where)
{
return this.objectSet.Where(where);
}
}

public interface IFooRepository
{
void DeleteFoo(Foo foo);
IEnumerable<Foo> GetItalianFoos();
}

public class FooRepository : Repository<Foo>, IFooRepository
{
public void DeleteFoo(Foo foo)
{
this.Delete(foo);
}

public IEnumerable<Foo> GetItalianFoos()
{
return this.Find(foo => foo.Country =="Italy");
}
}

使用抽象类而不是接口进行水管工程的好处是，我的具体存储库不必实现它们不需要的方法(例如，Delete或Add，但如果需要，它们可以随时使用。在当前上下文中，某些foo没有业务原因，因此该方法在接口上不可用。

对于业务模型，使用接口比使用抽象类的优势在于，接口提供了如何从业务端操作Foo的答案(删除一些foo是否有意义？创造一些？等等)。在单元测试时，使用这个接口也更容易。我使用的抽象Repository不能进行单元测试，因为它通常与数据库紧密耦合。它只能在集成测试中进行测试。将抽象类用于存储库的业务目的将阻止我在单元测试中使用它们。