【讨论】模块间调用设计

 

Web开发尤其是互联网相关的基本上需求是不停在增加的，以常用的blog的CURD功能举例；早期功能使用sql简单处理一下就可以了；一段时间后希望用搜索引擎代替数据库,

CUD时需要处理搜索相关的业务了；再过一段时间希望发表博客能够推送朋友动态功能等等；随着新事物、新技术的的兴起都会有新的改变吧；如何设计才能使得主模块的变动最小？

有些功能是不能影响主方法事物，如索引不成功不能使得整个保存过程失败。

解决方法一：代码堆积

 

public Blog save(Blog blog) {
	//持久化数据，调用数据层方法
		
	//索引处理
		
	//推送动态
		
	return blog;
}

 

解决方法二：aop

    这个完全不要更改主要代码模块。

解决方法三：监听机制

    实现相应的Lister就可以了。

解决方法四：异步调用（JMS）

目前没有研究过希望有会的可以指导下。

单个方法处理功能太多可能会影响到批量处理，如删除博客的分类，可能需求是同时删除其下所有博文，简单点可以通过sql级联一起删除；但同时还要删除索引等相关信息；总不至于查出分类下所有博文，在调用单个删除方法吧。不知各位有好的设计没，大家一起讨论一下。

我想你的问题可以分为3部分:
1. 方法逻辑的扩张。
2. 批量插入需求下的重构。
3. 是否应该删除数据。

如果你的重点是在第一个问题的话，在设计的时候就应该定义好接口的职责范围。
就你的例子来说，推送状态不属于数据层的职责。每次保存数据的时候改动索引也是一件比较奇怪的事情。
如果方法内出现了指责扩张，那可以进行职责抽象和细分。

重点是方法逻辑的扩张；这个方法是业务层的方法，职责划分后当发生改变时应通知到相应的handler，handler是会不断增加的，这部分如何设计？方法调用还是异步消息通知？内容的变了需要重新索引的。

Handler的定义应该由服务层提供，在数据层处理完了之后进行通知。
而外部逻辑可以实现该定义，再加入其队列。

至于是否异步处理跟方法逻辑的扩张本身没有关系，只是设计的时候对于某些情形这么处理罢了（比如IO操作时间比较长，就异步处理）。

我接触过的索引都是随着数据的插入数据库自动加的，也许你说的不是数据库的。

基于数据库的变化而通知索引，hibernate search是这样做的。由服务层调用Handler方法，从设计上可以是代码堆积一步步调用，也可以放在监听队列里或者异步通知的形式；我认为只要不影响主业务的、实时性要求不高的都可以异步调用；整体上应该抽象出一个主业务框架和辅助业务框架

果然不是数据库索引，那就没有讨论“索引”的必要了。

实时性是双向的，异步调用的确会降低目标的实时性，但保证了发起者的实时性。
比如这个例子里，如果发一条blog需要等到所有接受者都确认受到了才结束，那对发送者而言实时性和性能都是非常差的。

1 肯定是要异步的
2 aop所谓的拦截器和listener其实是一个东西。但是这里用aop不合适。aop这玩意貌似很先进，不需要修改原来的核心代码，但可读性不高，维护性差。aop一般用于全局性的一些业务，比如日志，安全，事务等。listener是否合理？要看情况。比如人家设计swing组件，和使用swing组件的人不是同一个人，甚至不是一个公司的人。他必须设计成listener。总之，如果负责添加listener的人和负责核心方法的不是一群人，这个模式是合理的。否则就是很可能是过度设计。

这个题目很大啊。简单的说：
模块间的依赖关系管理，OSGi是个不错的思路，无论开发期的还是运行期的osgi。
模块间的调用，统一的service管理（注册+发现）是个好主意。
简化的处理方式就是MQ/jms。

调用的几个方式：
同步，如果调用的业务比较简单，变化不大，响应较快，调用不是瓶颈的话，
同步是最方便的。
异步，如果业务复杂，调用比较慢，接口变化大，调用时瓶颈的话，异步（比如mq）是最好的方案，完全解耦。（根据实际场景看是queue或是topic）。
如果相关的系统比较多，需要统一管理控制，可以考虑使用ESB，统一管理这些服务和集成逻辑。