maven 多模块数据传输问题

逆流de鱼 发布于 2016/06/06 10:29
阅读 370
收藏 1
maven多模块划分,比如service模块和persist模块存在调用关系,当service层调用persist时的入参可能是个自定义对象(例如:user类),那在模块构建中这种传输对象时两个模块各自写一份,还是说单独写成一个模块专门管理这种入参出参的对象(这样的话各模块不能单独的编译测试),所以想听听大家的意见,是否有更好的方式来降低这种耦合调用
加载中
0
永远在一起

这个问题一般而言非常简单,service层调用persist意味着service对persist有依赖。直接将user类放入persist中就可以了。

至于你所说的两个方案,两个模块各自写一份是绝对不可行的,程序员不善于管理重复代码。当后期人员加入时,一个模块的变更,另一个模块肯定不能跟随变化。重复代码在设计时就应该杜绝。

单独写成一个模块是可以考虑的,特别是user类要被多个模块共享时。

但是我的推荐还是将user类放入persist模块中,需求复杂,很难保证能读取和修改user的模块竟然不需要将user持久化。

永远在一起
回复 @逆流de鱼 : 这是我从日志模块中学习到的,现在的习惯是约定优于配置。提供一个默认模块,不需要额外信息配置。不知道你是否了解slf4j和logback,这是非常好的例子。slf4j本身提供了一个NOP模块的默认实现,只是在开始时打印错误信息,随后不输出任何日志。slf4j可以看作你说的接口,logback可以看作你的具体实现。推荐参考。
永远在一起
回复 @逆流de鱼 : 从耦合分离来说,这种方式是比较好的方式。不过,建议在接口中提供默认实现(例如:抛出异常或者打印错误消息)。
逆流de鱼
逆流de鱼
恩恩,最好的方式应该是将interface和入参出参单独抽出来一个模块,然后persist和service分别依赖他,persist提供实现类,service完成调用,这样persist和service耦合度就降低了,而且两边都能单独编译,对嘛?
永远在一起
回复 @逆流de鱼 : 我思考了一下,或许你的意思是,在程序中抽象出了persist的接口,service依赖与此接口,但是不依赖于persist的具体实现模块。如果是这样子,user类最好和接口放在一起,因为user类也是接口的一部分。就user类来说,并不是个很好的例子,user类可以说系统的核心类,几乎每个模块都需要用到,单独写成一个模块应该更合适。
永远在一起
回复 @逆流de鱼 : 如果service对persist有依赖,service的单独编译似乎没有意义。
下一页
0
@ccny
@ccny

按模块开发,是要按实现的功能,业务进行区分。

如:

1.要做推送,那推送可能是一个模块

2.要做日志,日志是一个模块。

与业务无关,可以减少依赖,对于开发是很有好处的。

返回顶部
顶部