9

在我的职业生涯中，我看到了几个不同的设计，如何使用DAO, Service,Controller层。我想问两个，它们相似但几乎没有区别。第一个设计在层之间创建了可见的屏障。控制器总是使用服务并且只使用服务。服务可以使用其他服务或DAOs。控制器不能DAO直接使用任何。这种设计很清楚，但对我来说有很大的缺点：我们总是必须为DAO. 但在很多情况下，Service方法只调用DAOs 方法和其他任何东西。

例如：我们有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); }

    ......
}

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

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

各位，你们觉得这些设计怎么样？哪个更好？我应该在我的项目中使用哪些，哪些应该被遗忘？你能和我分享你在这方面的经验吗？

4

1 回答 1

3

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

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

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

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

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

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

于 2013-02-11T23:00:23.840 回答