最近看代码的时候,发现了一个奇怪的现象。关于调用批处理接口的问题。
如调用一个查询用户信息的接口为
UserInfo getUserInfo(String id)
则对应的批处理接口为
List<UserInfo> getUserInfoByIds(List<String> ids)
很多地方对该返回值进行了校验,即用for循环比对返回的UserInfo进行比对,担心返回的列表的长度和传入参数的长度不同,担心返回的列表的顺序和传入参数的顺序不同。
我觉得这样大可不必。调用批处理接口,应该是符合common sense的。
即可以返回一个null,可以返回一个empty list,其他情况都是返回一个大小和传入参数个数相等且顺序一致的列表。
如果有特殊情况,应该在方法的接口定义中特别声明,这样调用方的code会比较清晰好读,也符合一般人的直觉。让调用方做校验,这样的想法如果没有很强大的理由,还是不要的好,因为遵守默认约定,有可能服务方的代码会稍微复杂一点,但是考虑到多处调用方的代码的简洁和易读,这点代价完全是值得的。
如调用一个查询用户信息的接口为
UserInfo getUserInfo(String id)
则对应的批处理接口为
List<UserInfo> getUserInfoByIds(List<String> ids)
很多地方对该返回值进行了校验,即用for循环比对返回的UserInfo进行比对,担心返回的列表的长度和传入参数的长度不同,担心返回的列表的顺序和传入参数的顺序不同。
我觉得这样大可不必。调用批处理接口,应该是符合common sense的。
即可以返回一个null,可以返回一个empty list,其他情况都是返回一个大小和传入参数个数相等且顺序一致的列表。
如果有特殊情况,应该在方法的接口定义中特别声明,这样调用方的code会比较清晰好读,也符合一般人的直觉。让调用方做校验,这样的想法如果没有很强大的理由,还是不要的好,因为遵守默认约定,有可能服务方的代码会稍微复杂一点,但是考虑到多处调用方的代码的简洁和易读,这点代价完全是值得的。