Question

在“企业应用程序体系结构模式”一书中指出：

从层次上考虑系统时，您会想到主要子系统在软件中以某种形式的层蛋糕排列，其中每一层放在较低的层上。在此方案中，高层使用各种服务由较低层定义，但较低层不知道较高层。

另一方面，在“敏捷原理，模式和实践”一书中，有关依赖反转的原理阐述如下：

高级模块不应依赖于低级模块。两者都应该依靠在抽象上。

这让我感到困惑。我在这里混合两种不同的东西吗？

Answer 1

我想它可以说一些相同的原理，但粒度不同。但是，我仍然将依赖倒置视为独立的东西。

首先，考虑这个示例-在一个简单的分层体系结构中，您可能具有一个用JavaScript构建的表示层，一个用Java构建的业务逻辑层以及一个SQL Server的数据层。这些层可以由不同的人员团队开发。表示层知道如何对业务逻辑层进行API调用，但反之则不然。业务逻辑层知道如何与数据库层进行读写，但反之则不行。这里的区别发生在高层-您甚至可以将其称为概念性的。

在第二种情况下，您要防止假设通用代码依赖于特定实现的情况-在这一点上，我认为这是属于特定应用程序范围内的相对较低级别的关注（即在代码中），而不是像上一个示例那样在概念上）。如果您有写入数据库的代码，但想支持其他实现-例如MySQL和SQL Server中的每一个都可能具有某些特定的复杂性，因此它们不会使调用代码明确地依赖于两者中的任何一个，而是通过接口来消除复杂性。这就是依赖倒置原则所要解决的问题（见下文）。

    public class UserService {

        public UserRepository repository;

        public void setUserRepository(UserRepository repository) {
           this.repository = repository;  //Is this a MySqlRepository or a SqlServerRepository?  We don't care - the dependency is managed outside and we can change it without changing this class.
        }

        public void persistUser() {
            this.repository.persist(user);  //We just care about the abstraction - the interface.
        }
    }

Answer 2

我在这里混合两种不同的东西吗？

是的

第一种情况是关于运行时的依赖关系，而第二种情况是有关编译时的依赖关系。

例如，在运行时，业务层可以调用在数据库层中实现的功能/方法。但是在编译时，业务层代码没有在数据库层中提及任何代码。通常可以通过多态来实现。

有关软件设计/架构的查询

2 个答案: