Java模块通信
我有一个用 Java 编写的模块 - Web 服务模块，它接受请求处理它（这里是一些业务规则），在数据库中保存（修改或删除）值（使用 Hibernate），然后发送状态响应）。重构该模块是否合理，以便最终有 2 个模块 - 1 是 Web 服务模块，2 - 应用业务规则和进行数据库流程的处理模块？如果是，那么模块之间信息交换的良好做法是什么？ 谢谢 ！
I have one module written on Java - web service module which accepts request process it(some business rules here), saves(modify or delete) values in db (using Hibernate) and then send status response). Is it reasonable to refactor that module so at the end there will be 2 modules - 1 is web service module and 2 - processing module where business rules applied and db processes made? and if yes then what is the good practices for information exchange between modules ?
Thanks !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
记住“KISS”——保持简单；愚蠢的。
更重要的是拥有一个干净且可维护的代码，重点关注
领域模型，而不是基于技术考虑将其分解。
是的;数据库存储是一个方面，是的，处理Web服务调用是另一个方面，但是很容易花费大量时间来进行“干净”的分离，唯一的结果是以后更改内容需要更长的时间。 （所有从事 14 层“企业”应用程序工作的人都会告诉您。）
理想情况下，“业务逻辑”是您编写的一个模块，并且 Web 服务适配和数据存储应该“神奇地”工作。由于情况并非如此，您显然也必须处理这个问题，但这不是主要焦点。
我强烈建议：业务规则=你的数据模型。 Web 服务方法应尽可能精简，并尽可能干净地公开模型。
这是一篇关于“业务层”的颇有见地的文章 http://thedailywtf.com /Articles/The-Mythical-Business-Layer.aspx
还要记住，“层”是抽象概念，并且它们在不同的 Eclipse 项目等中“物理上”分离并不是基本要求。实际上，事实并非如此。
Remember "KISS" - keep it simple; stupid.
It's more important to have a clean and maintanable code, focused on the
domain model, rather than breaking it up based on technical considerations.
Yes; database storage is one aspect, yes, handling webservice calls is another, but its too easy to spend a lot of time to make a "clean" separation, with the only result that it takes longer to change things later. (As everone thats been working on an 14 layered "enterprise" application can tell you.)
Ideally, the "business logic" is the one module you write, and the webservice adaptation and the data storing just should work, "magically". As that is not the case, you obviously have to deal with that too, but its not the primary focus.
I strongly recommend that: the business rules = your datamodel. The webservice methods should be as thin as possible and expose the model as cleanly as possible.
This is a rather insighful article about the "business layer" http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx
Also remember that "layers" are abstract concepts, and its not a fundamental requirement that they are "physically" separated in diffent eclipse projects etc. Really, it's not.