彩信收发模块设计备忘录

彩信收/发后台模块设计备忘录

 

转载时请注明出处和作者联系方式：http://blog.csdn.net/absurd

作者联系方式：Li XianJing <xianjimli at hotmail dot com>

更新时间：2007-2-1

 

这两天在开发彩信后台收/发模块，它的功能是在后台异步接收和发送彩信。这样做的好处在于：一是不会阻塞用户界面，用户可以在收/发的同时做其它操作。二是可以不断的重试以提高收/发的成功率。整个设计并不复杂，但仍然有一些参考价值。写个备忘录，供有兴趣的朋友参考，也请高手指点。

 

整个收/发过程由彩信应用程序、数据库和收/发后台进程协同完成，其交互关系如下：

 

我们的数据库支持变化通知机制，它基于观察者模式。任何关心数据库变化的都可以向数据库订阅变化通知，当数据库有变化时，相关订阅者会收到数据变化通知。订阅时，可以订阅一张整表的变化，也可以设置规则只订阅表中特定条件数据的变化。

 

彩信应用程序和收/发后台都是数据库的订阅者，它们都可以更新数据库，也可以收到数据库的数据变化通知。

 

彩信应用程序收/发彩信很简单，发送时只要把记录的标志置为TO_SEND，接收时把记录(为彩信通知)的标志设置为TO_DOWNLOAD即可。

 

由于收/发后台订阅了数据库变化通知，此时它会收到数据库的通知。它查询数据库中待收/发的记录，当完成这些收/发工作，最后它设置记录成功/失败标志，并更新到数据库中。

 

同样由于彩信应用程序也注册了数据库的变化通知，此时它会收到数据库的通知，然后它查询数据库相应的记录，并提示给用户说收/发是成功还是失败。

 

用户也可以取消待发送的彩信，只要该彩信还在数据库或者发送队列中，用户就可以取消它。取消的过程也很简单，只要把相应的标志去掉即可。

 

彩信的收/发，如果失败，要重试一定次数(用户可设)，在网络状态不好的情况，这个过程可能要持续较长时间。我们允许用户取消待发送的彩信，收/发后台在收/发过程中，它还要接收来自数据库的通知。所以收/发后台需要两个线程并发运行，一个线程负责收/发，另外一个线程负责监听数据库的变化。

 

我们称收/发线程为工作线程，它与监听线程之间，通过一个队列通信。队列是共享资源，所以要加锁。它们的交互关系很简单：

 

这个实现并不复杂，问题是：在队列中放什么？有人说很简单啊，接收彩信和发送彩信是有差别，但这很容易区分开的，只要在请求中加一个标志就OK了，其余的事让工作线程去做。没错，这样可以实现功能，但是工作线程和队列就不能重用了，因为它与具体的任务关联起来了。以后如果在收/发邮件时也采用类似架构，我们是重写一个呢，还是在此基础上扩展呢？答案是两者都不好：前者造成代码不能重用，后者造成不必要的耦合。

 

怎么办了？如果我们对请求做个抽象，说到这里，有的朋友可能想起命令(Command)模式了。没错，就是它，工作线程只管工作，它不必知道它真正在干什么，具体的活由请求去做，它调用请求提供的函数即可了。

 

我们把请求调整为：

 

 

WorkerAction的接口函数主要有：

1.       execute：执行该请求。

2.       cancel：取消该请求。

3.       get_id：用于查找时比较。

 

另外我们还可以通过execute的返回值来决定继续重试还是放弃，工作线程一直重试，直到execute的返回值说不重试为止。

 

这样,工作线程和任务队列独立于具体的任务，它们变成了完全可重用的代码，其它需要异步执行的任务都可以重用它们了。

 

~~end~~