业务层和表现层之间的依赖注入

Question

我试图在我的软件中遵循干净的架构。我已经实现了 3 层：数据层、业务层和表示层。

据我了解，依赖会从外到内，如 P->B->D。

但我的问题是我应该将单例数据层执行程序注入到演示文稿中吗？这不是打破了这个逻辑吗？

或者没有 DI，只在层之间创建抽象我认为会产生紧密耦合。

因此，从业务层内部引用一些数据层依赖项 - 这不会使各层紧密耦合吗？

public class ViewModel<T> extends GenericRouter {
    IPresentation ip = new BusinessUseCaseImpl();

public abstract class BusinessUseCase<T extends HashMap> implements IPresentation<T> {

UserRepository urepo = new UserRepository();

Answer 1

这取决于你所说的“紧耦合”是什么意思。遵循三层架构，数据层依赖于业务层，业务层依赖于表现层。

您始终可以在接口上定义依赖注入，而不是注入具体的 class。有了这个，只要按照约定的接口，就可以随时切换实现。

但是，我的经验告诉我，对于基本和常规的 3 层架构，您很少或从不这样做。您始终只有一个服务和一个 Repository/DAO 实现，因此为它们每个都设置一个接口有点多余且无用。

我认为在使用 3 层架构时最重要的是永远不要绕过层。示例：

永远不要让表示层直接依赖于数据层。始终走业务层。
层之间的关系应该总是1:1。这意味着你不应该让控制器调用与另一个控制器关联的服务。

不遵守这些规则肯定会使您的代码难以阅读和理解。当然，每条规则都有例外，但请尽量遵守。

Answer 2

在干净的架构中，内层是逻辑，而不是基础设施。

当业务层实例化数据层时，它会注入它需要的任何基础设施依赖项。

同样，当表示层实例化业务层时，它会传入它需要的任何基础设施依赖项。这就是业务层如何获得它需要传递给数据层的基础设施。

最初，当 application/system 实例化表示层时，它会传入所需的基础结构。应该使用不起眼的对象模式来实现这些依赖关系，因为它们是系统的唯一部分，无法独立于基础设施进行测试。

业务层和表现层之间的依赖注入

Dependency injection between business layer and presentation layer

java

design-patterns

dependency-injection