面向异步消息的编程

从infoq淘到的一篇文章“Do Messages Want to Be Asynchronous?”，作者从头倒尾都在宣扬一个核心思想：为了实现一个robust  system,应该“Tell, Don’t Ask”。
暂时还没有实践作者的建议，实现一个由无返回值方法组成的小型的系统。无法深刻体会. 这里只是一点归纳性文字，传统的做法是由一个方法调用另一个方法，
然后等待其应答。作者的建议是将过程组织为一条单向的方法调用链，当然，只是叫下一个collaborator执行指定任务也存在弊端，由于是单向，就是无法对错误作出反馈。所以这里有人提议利用异常报告错误，将“Tell, don’t Ask”改为"Tell, don't ask, then be prepared when it all goes wrong"。
在方法调用链里面待处理数据作为异步消息传递，这样就避免了调用后的等待，在处理大量数据或是数据库操作的时候，无论在空间和时间上，优势都是很明显的。
    在整个系统中都使用无返回值的方法还从来没有尝试过，作者也说了这样做是将“Tell, Don’t Ask”推向了一个极至，我想合理的做法还是根据实际情况结合“Tell” 和 "Ask"

下面是原文的连接：
http://beautifulcode.oreillynet.com/2007/10/do_messages_want_to_be_asynchr.php

单向方法调用，从来没试过，不过感觉不太实际，方法无论你如何单向调用，等待反馈是一定需要的，只是看如何反馈而已，就像你所说的通过异常报告错误，这也是需要等待的，而且从本质上来看，一个方法被调用，即使没有设置返回值，但仍然会有返回，所谓的无返回也只不过是理解上的偏差而已，本质上没有区别，所以所说的避免调用后的等待我觉得并不成立，至少我是这样认为。

以我的感受整个系统的异步运行对提高系统响应确实有帮助，但是需要把运行错误当成日常事务，把具体逻辑设计成可恢复的。erlang的纯异步消息也是大概一样的意思，不过他有vm提供的error link机制来处理错误恢复，方便了很多。

但如果没有错误产生，不就不需要反馈了。当然只是无返回值，我
想还不算纯粹的"Tell",只能算是形式上模拟"Tell",上因为始终存在方法栈。而是应该如异步web应用那样，发送请求后就可以不管了。

例如我调用service层中的save方法保存一个order，然后service messaging dao将order insert 到数据库中。但不应该是

public void save(Order odr)
{
   dao.insert(odr);
}

但可以实现一个中转站,大致这样呢，

public void save(Order odr)
{
   sendToProcessList("save",odr，"nextCollaborator");
}

然后nextCollaborator在合适的时候去中转站去找到自己对应的任务。实际上也可以实现的

其实就像servlet在请求的时候提取request中的数据进行处理。

你所谓的如异步WEB发送请求后不管并不符合tell，因为WEB的异步如AJAX并非是真的不需要反馈，只是相对于不同的部分不需要反馈而已，而如果真要达到tell，那就必须像UDP传输那样，也就是如你所说的发送了就什么都不管，但是这并不适合特别是用户对数据库的操作，试想一下，当用户进行一个请求，但是该请求却是不可靠的连接，那会如何？

异步调用对于系统响应性能的主要影响是不需要阻塞，特别是在处理大量调用时尤其明显。

恩，用WEB异步应用举例是不完全符合Tell。真正的意思其实是认为‘接收者’会按照预期执行任务。比如前面提到的保存一张订单。service对客户下单动作作出反应，然后将数据通过异步消息的形式传递给dao,并预期dao会工作良好。如果dao失败，则通过异常的形式抛出。系统的每条链都以预期的形式执行，若遇到异常则马上抛出，那作为链中每个环节不就是可以不用管了嘛，因为service确定dao会完成付与的任务。

异步模型很好，只不过实现起来代价有点大。

我喜欢异步。

异步方式是操作系统的精髓之一啊。。。另：楼主头像是谁？