由于回调，使node.js与通常开发方式有所不同...详见内容。
正常进行服务端编程，当然会包括数据库的in和out… 但在使用Java或C#等进行服务端开发时，我们一般会建立一个DAO层来处理所有与DB操作相关的逻辑。 但node.js是基于回调的，node.js现在的mysql包也是使用回调的，这就有一个很明显的问题，返回结果会在异步回调函数之前执行，造成了返回结果为空。 不只这里有问题，安装正常服务端开发的逻辑，控制层或起调度分派作用的逻辑，同理当然也无法获得返回值。
如果摒弃Java或C#常规开发思想，让node.js后台使用回调会有几种方式来解决这个问题： 1，增加标记位，判断是否完成回调后，在进行返回结果——如果是只有一次或几次查询很简单，建立几个标记位即可，可是web开发，面临的不是几次查询那么简单。 2，使用轮询判断回调是否完成，浪费资源。 3，使用插件step，async等来进行同步控制。 4，回调的更彻底一些，把response作为参数传递到业务逻辑中，耦合性也太强了吧…
我刚刚接触node.js没多久，遇到这个问题很困惑，期待大家帮我来帮助我解决或者和一起来探讨这个问题
8 回复
改变想法，抛弃 MVC传统的思想 控制权转移流程由：
request > web server > controller (model,view ) > response
改成
request > web server > controller > model > view > response
这个应该才是 mvc的核心思维吧
- 我在用async
- 哈哈，我也是做java后端的。
- 我觉得node的异步可以用在这么几个场景，比如耗时比较长的调用、不需要强约束的业务逻辑、并行处理等等（把它异步高效的功能发挥最大用处，不要用它的弱项比其他语言的优势），虽然java的消息中间件（mq之类的）可以解决类似问题，但是node用起来小巧灵活、更方便使用（在java中来个回调可是麻烦了）。
- 最近在尝试使用node代替部分mq的功能。
我理解你的意思是这样的： controller接收请求后进行调度，然后就没它什么事了…随后在进行其他业务逻辑处理，直至返回结果。 原来的controller是等待model返回结果… 我的理解对么？
@jankuo 如果按照这个request > web server > controller > model > view > response 思路，只有自己搭建框架了…不过现在的思想一时间还转不过来…一直做传统意义上的后端开发，学习ing…
