我在很长一段时间内在一些3层应用程序中担任团队的一员。我喜欢这种架构，但在所有这些应用程序中，我注意到最顶层的两层对数据抽象层的依赖性很大。这使得测试和模拟变得困难，因为如果没有与大型数据库的现有数据库连接，实际上不可能运行应用程序或执行某些方法。是否存在试图解决此问题的模式？
答案 0 :(得分：1)
Dependency Inversion Principle（DIP，SOLID原则之一）完全解决了您描述的情况：
一个。高级模块不应该依赖于低级模块。都 应该取决于抽象。
B中。抽象不应该依赖于 细节。细节应该取决于抽象。
对于您的情况，特别是A部分是相关的：这些层应该仅依赖于可以以各种方式实现的抽象（例如，接口），而不是让UI和业务逻辑引用数据层。对于业务层，这意味着您定义业务层所依赖的接口。数据层提供这些接口的实现。
对于测试，您可以提供接口相关部分的另一种实现。这样，您可以准确提供测试中使用的数据，而不是准备好完整的数据库进行测试。
此模式也称为Inversion of Control。您会发现很快就会有几个接口，您需要在运行程序时提供实现。您可以使用abstract factories或 - 更简单 - 使用实现接口的具体类型的注册配置的控制容器反转来解决此问题。
在这方面您可能会发现有用的另一种模式是Repository pattern。