关于正确实现复杂服务层
我有以下情况：
三个具体的服务类实现一个服务接口：一个用于持久化，另一个处理通知，第三个处理为特定操作添加点（游戏化）。该接口大致具有以下结构：
public interface IPhotoService {
void upload();
Photo get(Long id);
void like(Long id);
//etc...
}
我不想将三种类型的逻辑混合到一项服务中（或者更糟糕的是，在控制器类中），因为我希望能够毫无问题地更改它们（或关闭它们）。当我必须将具体服务注入控制器才能使用时，问题就出现了。通常，我创建第四个类，大致命名为 ApplicationNamePhotoService，它实现相同的接口，并充当其他三个服务之间的包装器（中介），从控制器获取输入并调用每个服务相应地。尽管这是一种可行的方法，但它会创建大量样板代码。
这是正确的方法吗？目前，我不知道有更好的方法，尽管我非常想知道是否可以以声明方式（在上下文中）声明执行序列，并使用动态生成的包装器实例注入控制器。
另外，最好在三个服务之间缓存一些内容。例如，所有这些都使用 DAO，即有时一遍又一遍地对数据库进行相同的调用。如果所有逻辑都集中在一个地方，那么本来可以避免，但现在......我知道可以启用某些基于请求或会话的缓存。你能给我推荐一些示例代码吗？顺便说一句，我使用 Hibernate 来实现持久性部分。是否已经提供了一些缓存（可能，如果它们驻留在同一个事务或其他东西中 - 对于那个我完全迷失了）
I have the following situation:
Three concrete service classes implement a service interface: one is for persistence, the other deals with notifications, the third deals with adding points to specific actions (gamification). The interface has roughly the following structure:
public interface IPhotoService {
void upload();
Photo get(Long id);
void like(Long id);
//etc...
}
I did not want to mix the three types of logic into one service (or even worse, in the controller class) because I want to be able to change them (or shut them) without any problems. The problem comes when I have to inject a concrete service into the controller to use. Usually, I create a fourth class, named roughly ApplicationNamePhotoService, which implements the same interface, and works as a wrapper (mediator) between the other three services, which gets input from the controller, and calls each service correspondingly. It is a working approach, though one, which creates a lot of boilerplate code.
Is this the right approach? Currently, I am not aware of a better one, although I will highly appreciate to know if it is possible to declare the execution sequence declaratively (in the context) and to inject the controller with and on-the fly generated wrapper instance.
Also, it would be nice to cache some stuff between the three services. For example, all are using DAOs, i.e. making sometimes the same calls to the DB over and over again. If all the logic were into one place that could have been avoided, but now... I know that it is possible to enable some request or session based caching. Can you suggest me some example code? BTW, I am using Hibernate for the persistence part. Is there already some caching provided (probably, if they reside in the same transaction or something - with that one I am totally lost)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
服务层应由具有方法的类组成，这些方法是属于同一事务中的操作的工作单元。听起来您正在混合服务类，而它们可能位于同一类和方法中。您也可以在需要时将服务类相互注入，而不是创建另一个“中介”。
“混合三种类型的逻辑”是完全可以接受的，事实上，如果它们形成预期的用例/工作单元
缓存，我会考虑使用 eh 缓存，我相信它与 hibernate 很好地集成了。
The service layer should consist of classes with methods that are units of work with actions that belong in the same transaction. It sounds like you are mixing service classes when they could be in the same class and method. You can inject service classes into one another when required too, rather than create another "mediator".
It is perfectly acceptable to "mix the three types of logic", in fact it is preferable if they form an expected use case/unit of work
Cache-ing I would look to use eh cache which is, I believe, well integrated with hibernate.