Question

上的示例

我试图找出他提供的示例中首先需要服务层的原因。如果你把它拿出来，那么在你的客户端，你可以这样做：

UserDao userDao = new UserDaoImpl();
Iterator users = userDao.getUsers();
while (…) {
…
}

似乎服务层只是DAO的包装器。有人可以给我一个案例，如果服务层被删除，事情会变得混乱吗？我只是没有看到开始使用服务层的重点。

Answer 1

让服务层成为DAO的包装器是一种常见的反模式。在你给它的例子中肯定不是很有用。使用服务层意味着您可以获得以下好处：

您可以明确区分控制器中最佳的Web类型活动和非Web相关的通用业务逻辑。您可以与控制器逻辑分开测试与服务相关的业务逻辑。
您可以指定事务行为，因此如果您调用多个数据访问对象，则可以指定它们在同一事务中发生。在你的例子中，首先调用dao后跟一个循环，这可能包含更多的dao调用。将这些调用保留在一个事务中意味着数据库执行的工作较少（不必为每次调用Dao创建新事务），但更重要的是，这意味着检索到的数据将更加一致。
你可以嵌套服务，这样如果一个人有不同的交易行为（需要自己的交易），你可以强制执行。
你可以使用postCommit拦截器来发送电子邮件等通知内容，这样就不会破坏控制器。

通常，我的服务包含单一类型用户的用例，服务上的每个方法都是单个操作（在单个请求 - 响应周期中完成的工作），该用户将执行该操作，而不像您的例如，通常不仅仅是在那里进行简单的数据访问对象调用。

Answer 2

看看以下文章：

这一切都取决于您希望将逻辑放在您的服务或域对象中。

如果您具有复杂的体系结构并且需要与DAO和数据不同的接口，则服务层方法是合适的。为客户端调用提供课程粒度方法也很好 - 这可以调用多个DAO来获取数据。

但是，在大多数情况下，您想要的是一个简单的体系结构，因此请跳过服务层并查看域模型方法。 Eric Evans的Domain Driven Design和InfoQ文章在此扩展：

Answer 3

使用服务层是java社区中公认的设计模式。是的，您可以直接使用dao实现，但如果您想应用某些业务规则该怎么做。

比如说，您希望在允许用户登录系统之前执行一些检查。你会把这些逻辑放在哪里？此外，服务层是事务划分的地方。

保持你的dao层清洁和精益通常是好的。我建议你阅读文章“Don’t repeat the DAO”。如果您遵循该文章中的原则，您将不会为您的任何内容编写任何实现。

另外，请注意该博客文章的范围是为了帮助Spring的初学者。 Spring是如此强大，你可以通过像aop等强大的概念来弯曲它以满足你的需求。

此致詹姆斯