为什么要抽象数据访问层？ [关闭]

Question

当没有任何实现细节可用于当前代码范围时，应使用接口。

当您可以获得一些实现细节时，应该使用摘要。

查询 - 为什么仍然需要这些术语？为什么业务对象不能直接与 DataAccess.SqlServer 层通信？

Answer 1

当没有任何实现细节时应使用接口 可用于当前代码范围。

不是真的。你指的是封装。有“信息专家”的概念。只有知道如何做某事的班级才能做这件事。接口用于多态性和解耦。当使用代码希望以相同的方式处理某些类型的对象时，该代码可以通过将所有这些对象视为接口类型来以相同的方式使用它们。

当一些实现细节不明确时，应该使用摘要 可供您使用

我不确定你在这里的意思。我认为你很困惑，因为这听起来不对。抽象类的使用方式与接口相同，但允许在其中实现。

查询 - 为什么仍然需要这些术语？为什么不能业务对象 直接与DataAccess.SqlServer层通信？

他们可以，但以可维护性、灵活性和可测试性为代价。如果你想用另一个替换你的数据层，你不能因为消费代码直接依赖于当前数据层。如果你想对你的逻辑进行单元测试，你不能不打数据库。如果您将数据库类放在接口后面，您可以在单元测试中模拟数据层并测试您的逻辑类而无需访问数据库。

非常简短的示例

public Foo FooLogic
{
    IFooData fooData = DataAccessFactory.GetDataClass<IFooData>();
    return fooData.GetFoo();
}

现在您的逻辑类不再绑定到特定的数据类。工厂可以返回一个真正的 FooData 实现，也可以返回一个模拟数据对象，或者可以在不影响逻辑类中的代码的情况下放置一个新的数据访问层。