哪种设计模式更适合与控制器/服务/ DAO一起使用

Question

在我的职业生涯中,我看到了几个不同的设计,如何使用DAO,服务,控制器层.我想问一下两个相似但差别不大的两个.第一种设计在层之间产生可见屏障.控制器始终使用服务而仅使用服务.服务可以使用其他服务或DAO.控制器不能直接使用任何DAO.这个设计很清楚,但对我来说有很大的不足:我们总是要为DAO中的每个方法创建服务方法.但在很多情况下,Service方法只调用DAO方法和其他任何东西.

例如:我们有 DAO

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

    ......
}

控制器使用上述所有方法.在我们的案例中我们应该做些什么？创建类似的方法Service:

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); }

    ......
}

对我来说,这是只读方法的额外不必要的层.

在第二种设计中,我们没有遇到任何问题,因为我们可以在控制器中直接使用DAO.在这个设计中我们有一个规则:如果我们想从"数据存储"中检索数据,我们可以在任何层使用DAO,如果我们想在"数据存储"中进行一些更改,我们必须使用服务方法.

伙计们,对于这些设计你怎么看？哪个更好？我应该在我的项目中使用哪些应该被遗忘？你能和我分享你在这方面的经验吗？

Answer 1

在 MVC 和受 MVC 启发的设计模式中，服务是模型层的“顶部部分”。这就是表示层与域业务逻辑交互的方式（实际上，“读取”部分应该由视图实例完成）。

在这种结构中，服务充当屏障，隔离表示层，并为您提供稍后更改模型内部结构的额外自由。

您必须记住的另一件事是，与服务交互的结构不仅仅是DAO 。首先，领域对象（业务对象、模型对象）封装了与一个特定实体相关的不同业务规则。然后，您还可以拥有数据映射器，它抽象存储逻辑而不是 DAO。或者在映射器和域对象之间转换信息的 DAO。在更大规模的应用程序中也会有工作单元。在较小的规模中，您可以使用一些活动记录实例。

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

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

如果您公开 DAO，您的模型层就会在演示文稿中开始泄漏。控制器不应该知道使用了什么结构以及它们何时被持久化。