问个接口设计问题

[吾非大神]

需求是这样的
要开发一个相对独立的消息平台，主要用来提供发消息的功能
比如发邮件、发短信、或者直接对业务系统进行发通知消息
自己想的是 只对外提供一个接口，让调用者指定发送方式，但是各类消息所需要的参数是不一样的
比如 邮件 需要邮件地址，发件人，接收人等；短信则需要电话号码；而直接发到业务系统，可能就提供一个URL了

现在不知道如何来设计这个参数，来尽可能的满足多种方式的消息发送。
请各位指点一二，多谢。

[我真的不是菜鸟]

{"Method":"邮件","参数1",:"1","参数二":"2"}

邮件的请求

{"Method":"短信","参数1":"1"}

短信的请求 服务器对请求类型进行判断

if(Method == 邮件)
    return 邮件响应内容
else if(Metthod==短信)
    return 短信响应内容

[md5e]

.net 的话一般用webservice

[md5e]

可以参考短信易的接口参数

[吾非大神]

引用 2 楼 vb763305825 的回复:

{"Method":"邮件","参数1",:"1","参数二":"2"}

邮件的请求

{"Method":"短信","参数1":"1"}

短信的请求 服务器对请求类型进行判断

if(Method == 邮件)
    return 邮件响应内容
else if(Metthod==短信)
    return 短信响应内容

如您所列，这样的方式已经考虑，但是现在就是一个 两种或多种组合 比如 发邮件同时通知到系统 这种组合， 我考虑把他们抽象出父类出来，然后调用者传递发送方式的集合过来（调用者就需要定义和消息平台同样的 父类 子类关系） 感觉这样 调用者做的工作貌似有点多。。不知道有没有其他好的方式

[liajun1221]

interface IProcess { string ProcessName{get;} } abstract class Process<T>:IProcess { public String ProcessName { get{return typeof(T).Name;} } abstract void Send(T message); } public class SMSProcess:Process<SMS> { override void Send(SMS message) {} } 再自己封装一个工厂类 决定每次调用具体的流程就行了

[吾非大神]

引用 3 楼 liuchaolin 的回复:

.net 的话一般用webservice

网上没找到它们。。

[tcmakebest]

这个问题其实是用什么类型来保存不同类型的参数的问题,很简单,用JSON或者XML.

[我真的不是菜鸟]

觉得没有必要这么复杂啊，还不如直接加一个“发邮件同时通知到系统”的方法。

[我真的不是菜鸟]

调用者只要遵守服务器给出的接口范式来用就行了，该用什么参数就填什么参数，管那么多复杂的子父类关系干嘛。 服务器暴露出来的接口尽量要简单清晰明了啊，能让人简单愉悦地使用的接口才是好接口

[吾非大神]

引用 10 楼 vb763305825 的回复:

调用者只要遵守服务器给出的接口范式来用就行了，该用什么参数就填什么参数，管那么多复杂的子父类关系干嘛。 服务器暴露出来的接口尽量要简单清晰明了啊，能让人简单愉悦地使用的接口才是好接口

这样 可能就得分写成几个接口，然后由调用者来决定使用哪一个 或 哪几个了。

[我真的不是菜鸟]

也可以在一个功能差不多的通用接口里面加参数判断"调用该接口的同时是否要通知系统"之类的，看你自己怎么取决

[wanghui0380]

额，各自负责各自滴，这才是接口，才是重载，才是对象 让你在上面还统一规定如何调用，传什么参数，那不是接口的含义，至于你非要规定参数，那么请抽象他，抽象玩了，内部各自转换各自滴，转换错误或没有对应属性，请抛异常，说明参数不是这方法期望滴就ok

[於黾]

我觉得你这个问题应该先分解,不要都搅到一起 1.调用这个接口(或者类,或者平台,谁知道最后是个什么)的地方,如何调用 可能就只需要知道发给谁,发邮件还是短信还是内网还是飞秋......最后就只需要2个参数,一个是发给谁,一个是发到哪 2.具体往外发的时候,需要根据发到哪,去匹配对应的信息 比如发到邮箱,你就必须知道用户邮箱,发到短信,你得找到手机号,发飞秋,你需要知道IP,发内网,你需要知道用户在数据库中对应的ID 总之,调用的人不应该关心每个用户的IP,手机号,邮箱什么的,那些都应该存到数据库里去. 调用的地方只需要知道发给谁,发到哪,至于你怎么发,我不管.

[吾非大神]

引用 13 楼 wanghui0380 的回复:

额，各自负责各自滴，这才是接口，才是重载，才是对象 让你在上面还统一规定如何调用，传什么参数，那不是接口的含义，至于你非要规定参数，那么请抽象他，抽象玩了，内部各自转换各自滴，转换错误或没有对应属性，请抛异常，说明参数不是这方法期望滴就ok

我理解您的意思，我也是想往这方面去考虑，可是我把上面那些东西都考虑上之后，就成了这样了。。。所以来求指导来了

[吾非大神]

引用 14 楼 Z65443344 的回复:

我觉得你这个问题应该先分解,不要都搅到一起 1.调用这个接口(或者类,或者平台,谁知道最后是个什么)的地方,如何调用 可能就只需要知道发给谁,发邮件还是短信还是内网还是飞秋......最后就只需要2个参数,一个是发给谁,一个是发到哪 2.具体往外发的时候,需要根据发到哪,去匹配对应的信息 比如发到邮箱,你就必须知道用户邮箱,发到短信,你得找到手机号,发飞秋,你需要知道IP,发内网,你需要知道用户在数据库中对应的ID 总之,调用的人不应该关心每个用户的IP,手机号,邮箱什么的,那些都应该存到数据库里去. 调用的地方只需要知道发给谁,发到哪,至于你怎么发,我不管.

比如您提到的第二条，这些信息都在调用方那里，所以需要他们提供过来。

[於黾]

引用 16 楼 xl_0715 的回复:

[quote=引用 14 楼 Z65443344 的回复:] 我觉得你这个问题应该先分解,不要都搅到一起 1.调用这个接口(或者类,或者平台,谁知道最后是个什么)的地方,如何调用 可能就只需要知道发给谁,发邮件还是短信还是内网还是飞秋......最后就只需要2个参数,一个是发给谁,一个是发到哪 2.具体往外发的时候,需要根据发到哪,去匹配对应的信息 比如发到邮箱,你就必须知道用户邮箱,发到短信,你得找到手机号,发飞秋,你需要知道IP,发内网,你需要知道用户在数据库中对应的ID 总之,调用的人不应该关心每个用户的IP,手机号,邮箱什么的,那些都应该存到数据库里去. 调用的地方只需要知道发给谁,发到哪,至于你怎么发,我不管.

比如您提到的第二条，这些信息都在调用方那里，所以需要他们提供过来。[/quote] 让他们维护一个人员表,然后平台去表里取信息就行了,不用每发一次,都传一次完整的参数吧. 要做成那样,你只能为每种方式做不同的接口,他们想怎么调用自己玩去. 想发完邮件再发内网,自己写2遍代码. 否则你在同一个接口里定义了许多用不到的参数,用起来更费劲.

[smthgdin_020]

引用 11 楼 xl_0715 的回复:

[quote=引用 10 楼 vb763305825 的回复:] 调用者只要遵守服务器给出的接口范式来用就行了，该用什么参数就填什么参数，管那么多复杂的子父类关系干嘛。 服务器暴露出来的接口尽量要简单清晰明了啊，能让人简单愉悦地使用的接口才是好接口

这样 可能就得分写成几个接口，然后由调用者来决定使用哪一个 或 哪几个了。[/quote] 我觉得还是尽量保持接口稳定，实现接口的方法尽量简短，不要建立实现多种传送的方法。 1个方法实现发邮件，1个方法实现发短信就行，不要用1个综合的方法来实现，其实调用者只是多调用1次而已。好处就是你的系统比较稳定，不然那天有个要发3种类型的，你又要新增方法。

[btman52]

类似于微软的webrequest，自定义uri+类厂，处理uri的类在类厂中注册scheme，类厂根据传入uri的scheme创建并返回接口实例： 例如通知日志系统：log://logserver/ErrorReport 短信：sms://smsproxy/13333333333 http：http://server/svc.asmx 具体发送的逻辑都封装在向类厂注册的类中，对调用方来说完全透明。数据传输最好自己组装成为byte[]，json和微软序列化都影响性能。 参考：http://msdn.microsoft.com/zh-cn/library/system.net.webrequest

[whowhen21]

通用的可以放两个参数即可，一个是method，一个args，args是json格式的，后台解析json，根据method执行指定方法，传入参数。可以加上参数验证方面的，确保接口安全。 eg: xxx.com/sendMessage?method=sendSMS&args={mobile:"138xxxxx",content:"hello"}&token=XXXXXXXXXXXXX xxx.com/sendMessage?method=sednMail&args={to:"[e-mail]",cc:"[e-mail]",content:"hello"}&token=XXXXXXXXXXXXX

[泛用人形代码复制机]

我觉得json最好 简单粗暴,还适应性强, 不过注意jsn需呀尽快集中反序列化,别让他到处扩散.