近来学习nodejs,觉得事件驱动模型是个十分美好的东西。

这里最强大的是事件驱动这个概念本身。具体实现是次要，各个语言里都有。

一些零散的心得。零碎不成章，仅供自己作为笔记使用。

事件驱动,异步，回调函数常常是同时出现的。 回调让动作能按照逻辑顺序执行。回调让编程人员只要安排好任务就行，不要在意其发生的具体时间。

基于事件驱动的编程的基本想法是 ： 监听某些感兴趣的事件，当它发生时，触发我们的处理函数。

一些良好特性：

• 事件处理者可以拿到关于该事件的任何数据(传入回调函数)
• 松耦合，事件发布者和处理者无须知道对方的存在。
• 多对多的关系，多个事件发布者对应多个处理者（订阅者）

最近学生处需要做一个学生资助管理系统，朋友接了这个项目，是一个典型的管理系统，涉及的逻辑较多（后台可执行的”动作“较多），需求还算清晰。

系统使用django来写,当尝试使用事件驱动的概念来编程时(django中使用信号Signals来通知事件发生，当event（事件）发生时，signals（信号）允许若干 senders（寄件人）通知一组 receivers（接收者）)，发现能降低复杂度，比如通过监听某个对象被修改这个事件,(post_save)，可以不需写view，在数据更改时，对与它关联的其他数据状态也进行修改。这样不需要侵入到后台逻辑。

更多django相关信号

这里有些像观察者模式？

这种模式很适合做些数据验证的工作， 监听pre_sava事件就行。

也引发了自己对设计模式的一些思考。

思考具体问题时，把它抽象化表述，逻辑层或者数据层，这样在抽象的世界里，方法是通用的,这样容易找到合适的设计模式。也就是通用的解决方案。大多问题前人都遇到。在抽象层我们面对的许多问题是极其相似的，我想这也就是设计模式被总结出来的初衷。

我把归纳为，先后退再前进。

退回到问题的一般表述，找到思路后（吸取别人的经验），在回归具体问题。

文章作者 种瓜

上次更新 2014-04-14