oop - 哪种设计模式更适合与Controllers/Services/DAO一起使用

Question

在我的职业生涯中，我看到了几种不同的设计，以及如何使用DAO，Service和Controller图层。我想问两个，它们相似但相差无几。
第一种设计在层之间创建可见的屏障。 Controller 始终使用服务，而仅使用服务。服务可以使用其他服务或DAO。
Controller 不能直接使用任何DAO。这种设计很清楚，但对我来说却有一个很大的缺点:我们总是必须为DAO中的每个方法在服务中创建方法。
但是在很多情况下，Service方法仅调用DAO的方法以及其他任何方法。

例如:
我们有UserDao

class UserDao {
    public List<User> findByName(String name) { ... }
    public List<User> findByLastName(String name) { ... }
    public List<User> findOlderThan(int age) { ... }

    ......
}

Controllers使用以上所有方法。我们该怎么办？在 UserService中创建类似的方法:

class UserService {
    public List<User> findByName(String name) { return userDao.findByName(name); }
    public List<User> findByLastName(String name) { return userDao.findByLastName(name); }
    public List<User> findOlderThan(int age) { return userDao.findOlderThan(age); }

    ......
}

对我来说，这是只读方法的另一个不必要的层。

在第二个设计中，我们对此没有问题，因为我们可以直接在Controller中使用DAO。
在此设计中，有一条规则:如果要从“数据存储”中检索数据，则可以在任何层中使用 DAO，如果要在“数据存储”中进行某些更改，则必须使用服务方法。

伙计们，您如何看待这些设计？哪个更好？我应该在项目中使用哪些，而应该忘记哪些？您能与我分享您在这方面的经验吗？

Answer 1

以MVC和MVC为灵感的设计模式中的服务是模型层的“顶部”。这就是表示层与域业务逻辑交互的方式(“读取”部分实际上应该由 View 实例完成)。

在这种结构中，服务充当了障碍，它隔离了表示层，并为您提供了以后更改模型内部结构的更多自由。

您还需要记住的另一件事是，服务交互所使用的结构比DAO还要多。首先是domain objects(业务对象，模型对象)，它封装了与一个特定实体相关的不同业务规则。然后，您还可以拥有data mappers，它抽象存储逻辑而不是DAO。或在映射器和域对象之间转换信息的DAO。在更大范围内，应用程序还将具有unit(s) of work。在较小的规模上，您可以使用一些active record实例。

您可以说模型层包含三个主要的结构组，在其中实现了模型的各个方面:域，存储和应用程序逻辑。

应用程序逻辑是存储结构域对象之间的交互。这就是服务所负责的。

如果公开DAO，则模型层将在演示文稿中开始泄漏。 Controller 不应该知道使用了什么结构以及何时保留它们。