后台相同的操作,不同的第三方平台,不同的请求和响应内容, 有可能封装成一个统一的操作接口吗

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2626 天前的主题，其中的信息可能已经有所发展或是发生改变。

大家好, 现在被这个问题困扰了,不知道有没有解决过类似问题的老哥, 先感谢.

情况是这样的, 因为功能涉及到对接多个第三方平台, 但是操作都差不多, 如 查询商品, 预定, 退款, 查询订单信息等, 我原想用一个接口统一操作接口, 但是蛋疼的地方在于每个平台的请求和响应消息体都不一样, 想通过相对来说扩展性高, 以后添加其他平台等都比较方便的方式解决. 大家有遇到过这样的问题吗, 最后又是怎样搞定的呢? 多谢多谢. 头都大啦.

操作

接口

平台

请求

23 条回复 • 2017-09-20 20:23:35 +08:00

keysona

2017-09-20 10:01:59 +08:00

也配到类似的需求。

app <--> my server <---中间层---> n 个第三方

弄个中间层把 server 和第三方对接起来就行了。

zgbgx1

2017-09-20 10:02:50 +08:00

你的 DAO 和 service 层来执行相同的 db 操作，更上层，每个请求就一个 action，每个的 action 的 request 处理和 response 生成都每个接口写一个

BBCCBB

2017-09-20 10:10:51 +08:00

@keysona en... 能具体点吗,中间层是指??? thx.

BBCCBB

2017-09-20 10:13:48 +08:00

@zgbgx1 thx. 就像我说的,和你这个思路应该一样的. 采用策略模式的思路定义接口, 然后为每个平台实现具体的逻辑操作, 但是还要根据每个不同的平台对每个方法的参数进行不同的构造, 如果接口里方法太多, 参数构造的代码很繁琐, 但是这是目前我能想到的最好的方式了.. 23333 .

cenxun

2017-09-20 10:16:03 +08:00

定一个抽象类，不同平台不同实现，上层调用相同

BBCCBB

2017-09-20 10:18:41 +08:00

@cenxun 我描述里也是这样想的, 但是每个平台请求响应参数不尽相同, 这就是尴尬的地方.

SilentDepth

2017-09-20 10:21:00 +08:00

最简单的 if-else 不可以？参数不一样就怼不一样的参数上去呗

BBCCBB

2017-09-20 10:23:25 +08:00

@SilentDepth 23333, if-else 最大的问题在于代码膨胀很快,可维护性低, 我们要对接的平台有点多, 所以 if-else 不可行啊

annielong

2017-09-20 10:25:23 +08:00

要么做一个可扩展的强对象，统一在对象中处理，要么做 case，一种请求一个 action，反正都有利有弊，视具体情况而定

SilentDepth

2017-09-20 10:27:39 +08:00

@BBCCBB #8 不同平台不同接口，你无论怎么做都要有一层 if-else 啊，不然程序怎么知道要怼哪些参数上去。如果不同平台的接口定义有一定的规律，可以简化 if-else 的级数

BBCCBB

2017-09-20 10:33:03 +08:00

@annielong 好像只能这样了, thx

BBCCBB

2017-09-20 10:33:57 +08:00

@SilentDepth 是的, 我只是来看看有没有什么牛逼的巧妙的解决办法, hahahha~

cenxun

2017-09-20 10:37:52 +08:00

这样呢
```code
handler = platform::getInstance();
handler->setParam(paramA, paramB, paramC, ...)->handle();
```

BBCCBB

2017-09-20 10:44:32 +08:00

谢谢楼上各位, 我决定这样处理,
1. 采用策略模式定义接口, 接口里的方法参数和返回参数自己定义(只处理我们需要的), 不采用平台的,
1. 将我本地请求操作的所有参数封装成对象传入方法, 然后不同第三方平台的方法实现里通过传入的参数对象构造自己需要的请求对象
1. 请求完成后, 封装成我需要的信息的结构, 然后返回给我

BBCCBB

2017-09-20 10:45:17 +08:00

@cenxun 老哥,你这是 php 吗, 23333, 看不懂啊....

pynix

2017-09-20 10:47:19 +08:00

adapter

klgd

2017-09-20 10:56:49 +08:00

适配器模式？

RubyJack

2017-09-20 12:01:21 +08:00

适配器模式

BBCCBB

2017-09-20 12:20:05 +08:00

@pynix
@klgd
@RubyJack 这个地方说策略和适配器模式都适用, 主要是不同请求参数的处理有点懵逼, 但我现在决定采用我再 #14 楼写的方法处理参数, 有兴趣的话可以帮我看看有没有什么问题??

mingqing

2017-09-20 14:22:28 +08:00

有个东西叫接口网关，专门解决这种需求

loveCoding

2017-09-20 14:30:53 +08:00

正好做这方面的工作 ,我的经验是 :
1.对外-针对每个平台分成不同的接入层 , 不要想在一个接口里面做太多的工作,接入层的作用就是请求鉴权,参数解析和响应,处理异常情况 ,一旦涉及到需求变更可以放心大胆的去改. 低耦合,好维护,好写测试.
2.对内-业务逻辑在 service 层 ,这个是你自己系统的业务,肯定是可以做抽象出一部分的.细微区别可以多使用方法重载 ,尽可能的分割函数功能以便重用代码. 尽量做抽象,代码重用,好写测试.

最后: 业务复杂度高了往往是个死结,无解,该 if 就 if ,不过咱们作为开发者写代码时多站在使用者的角度来考虑和设计 api ,为什么很多人推崇测试驱动呢?就是因为写单元测试时你自己是先作为使用者, 你准备设计的 api 好不好用单测一写就知道.

BBCCBB

2017-09-20 15:23:48 +08:00

@mingqing 搜索了一下,还是比较懵逼接口网关...

@loveCoding 老哥,你这两条好抽象, 和我#14 楼有什么相似之处吗?

HaoyangWei

2017-09-20 20:23:35 +08:00

像这种问题没有通过垫一层解决不了的，如果有，那就垫两层。