正确实施复杂的服务层

Question

我有以下情况：

三个具体的服务类实现服务接口：一个用于持久性，另一个用于处理通知，第三个用于向特定操作添加点（游戏化）。界面大致具有以下结构：

public interface IPhotoService {
   void upload();
   Photo get(Long id);
   void like(Long id);
   //etc...
}

我不想将这三种类型的逻辑混合到一个服务中（或者更糟糕的是，在控制器类中），因为我希望能够毫无问题地更改它们（或关闭它们）。当我必须将具体服务注入控制器以供使用时，问题就来了。通常，我创建第四个类，大致命名为ApplicationNamePhotoService，它实现相同的接口，并作为其他三个服务之间的包装器（中介），从控制器获取输入，并相应地调用每个服务。这是一种工作方法，虽然可以创建大量的样板代码。

这是正确的做法吗？目前，我不知道一个更好的，虽然我将非常感谢知道是否有可能以声明方式（在上下文中）声明执行序列，并注入控制器和飞行生成的包装器实例。

此外，在三个服务之间缓存一些东西会很好。例如，所有人都在使用DAO，即有时一次又一次地对DB进行相同的调用。如果所有逻辑都放在一个可以避免的地方，但现在......我知道可以启用一些基于请求或会话的缓存。你能给我一些示例代码吗？顺便说一下，我正在使用Hibernate作为持久性部分。是否已经提供了一些缓存（可能，如果它们存在于同一个事务或其他事情中 - 那个我完全丢失了）

Answer 1

服务层应该包含具有方法的类，这些方法是具有属于同一事务的操作的工作单元。听起来你正在混合服务类，因为它们可能属于同一个类和方法。您也可以在需要时将服务类注入其中，而不是创建另一个＆＃34; mediator＆＃34;。

将三种类型的逻辑＆＃34;混合在一起是完全可以接受的，事实上，如果它们构成预期的用例/工作单元，则更为可取

缓存我希望使用eh cache，我相信它与hibernate完全集成。