这是一个创建于 2226 天前的主题，其中的信息可能已经有所发展或是发生改变。
全提出来，会不会太多余了，其他服务又不需要
但不提取出来吧，调用其他服务返回的参数，需要一个实体类接收（另一个服务里有这个实体类），再写一个太重复了吧
还是用到哪个，就提取哪个？
第 1 条附言 · 2018-10-23 16:28:09 +08:00
我打算把 VO 提取到公共模块（项目里的 VO 和 DTO 是一个东西，人懒，没分这么细），这样能避免大量引入多余的类了，虽然还是存在
第 2 条附言 · 2018-10-23 17:41:55 +08:00
我收回上一条说的 - -
 |
1
passerbytiny 2018-10-23 15:31:55 +08:00
既然你都能感受到多余了，那么就需要设计一个媒体数据读取工具了。接收方，直接按需从 json 中读取数据，不需要反序列化成对象。
另外说明一点，既然是微服务，不是远程调用，那就要解耦的，两个服务之间是不应该存在一模一样的实体的。服务之间通信时传递的应当是契约数据，而不是某个类的对象。 |
 |
2
mortonnex 2018-10-23 15:41:08 +08:00
我们是多个服务存在多个相同的实体类,其实这个不算重复
|
|
3
mortonnex 2018-10-23 15:42:52 +08:00
@passerbytiny
"按需从 json 中读取数据" 这种也可以,但是有一点不足,就是后面维护的人,不知道 jsonObject 里面到底有哪些数据,如果后面要使用到别的数据,那么会有沟通成本 其实这也是不提倡用 map 接收数据的原因,因为实体类更清晰 |
 |
4
p2pCoder 2018-10-23 16:06:46 +08:00
数据库实体 bean 以及业务相关的 VO 之类不用提取成 公共模块
通信过程中 的 参数 可以封装成 dto，暴露相应的服务 api 包出去就行，这中间涉及序列化。原则上，业务相关的 bean 不应该直接暴露，暴露的应该是调用方需要的 dto 信息 当然如果不是纯粹的微服务，只是业务太复杂需要拆分并且也做不到分库，数据库的 bean 也会暴露出去 这是我这个菜鸡的理解 |
 |
5
monsterj OP @passerbytiny 我不太喜欢 JSON 和 Map 接收，因为这样字段不清晰，后续维护和开发麻烦
|
|
6
passerbytiny 2018-10-23 16:28:44 +08:00
@mortonnex #3
沟通需要的是接口文档。 媒体数据读取工具不是用 map 接受数据，而是类似于 json path。如果有多层嵌套数据，多层数据类绝对没有 json path 清晰。 初期可以用数据类加自动反序列化来快速接受数据，后期接口多了并且迭代频繁的时候，数据类就不适合了。 |
|
7
passerbytiny 2018-10-23 16:31:38 +08:00
@monsterj #5 假如接口提供方迭代频繁的时候，你会觉得数据类修改起来更麻烦。
|
|
8
mortonnex 2018-10-23 16:34:08 +08:00
@passerbytiny 你也许没懂我的意思,算了
|
|
9
monsterj OP @passerbytiny 各有利弊吧
|
Select Language