Web services 将数据库操作公开为Webservice

情景：

在我的项目中，我们有一个web服务（apachecxf、Hibernate和Spring）来向第三方公开一些服务，门户（springmvc、Portal和Hibernate）用于开发前端web应用程序，还有一些单独运行的批处理（springbatch、Hibernate）操作

所有3个应用程序都使用相同的数据库，并且在应用程序级别具有映射和实体管理器

问题:

上面的场景几乎在3个位置更新相同的映射，我们无法启用缓存，因为相同的实体将在多个应用程序中更新，并且每个应用程序都有单独的实体管理器

我的解决方案：

我计划引入一个web服务，它将负责所有的数据库操作，并将被其他3个应用程序使用。这样可以避免上述问题

---

您能帮我调整解决方案或帮助我找到新的最佳方法吗？

Ganesh，将您对数据库的更新集中在一个地方，如您所述，这将有助于您解决这种情况。您没有描述的是如何公开web服务以及理解表关系的真正工作发生在哪里

通过进行更改，您可以获得的真正优势是将表更新的业务逻辑集中在同一web服务中（或者可能在其他地方）。然后，web服务可以公开业务对象

一个典型的简化示例：

Business Purchase Order = Table Purchase Order + Table Purchase Order Lines + Stock Available reduced by Order Quantity 业务采购订单=表格采购订单 +表1采购订单行 +按订单数量减少的可用库存 我最不希望的是多个应用程序必须管理这些表更新，或者必须以紧密绑定的关系调用Stock应用程序以减少可用库存。但是，公开业务采购订单并担心新web服务中的相关表更新会确保每次增加系统的可维护性时都以相同的方式进行

如果你把Web服务的曝光看作是对象的组合，如下所示，那么你可能会考虑是否要重新思考Web服务真正在做什么以及是否需要另一层抽象，但这是一个较长的讨论。 WEB SERVICE +-------------------+ | Service Contract | +---------+---------+ Message -> | Message | Core | + Parsing | Service | <-> Backend <-> Persistent Storage Message <- + Logic | Logic | + other +---------+---------+ Services 网络服务 +-------------------+ |服务合同| +---------+---------+ 消息->消息|核心| +解析|服务|后端持久存储

---

留言谢谢@geoffc。。我确实有一些想法，但你给了我一张极好的图片，让我在各个方面都能思考。。。现在与团队一起讨论此更改。谢谢你的帮助。