记得阿朱在《走出软件作坊》一书中有一章讲客户提的需求太邪门了，鼠标键盘不太会用要程序员开发一个语音输入功能，还要系统中带类似QQ的功能；确实刚开始的客户的想法有点天真，但是随着信息化的越来越普遍，客户对信息系统也比较了解，特别年轻的信息管理人员，除了接受能力强，并且长期站在客户的角度对信息系统也有一些独特的见解，跳出技术框框外的想法；

      其中有个年轻的信息人员聊天的时候说了一些对系统的要求，其中有一个功能是这样的，部门人员向库房申请一批物资，以前的做法就是先把申请单内容录入系统，然后再电话通知库房人员叫他们审核申请单，审核完后核对没有问题，库房人员再打电话通知他们什么时候送货过来；现在听了他的意见改进后，部门人员录完申请单，保存的时候系统自动发送一条消息给所有库房人员，库房人员的电脑会弹出一个类似QQ的通知框，库房人员就会马上审核此申请单，然后审核完成后，系统又会自定生成一条消息发给接收部门；全程再也不需要电话联系，系统给人带来一种比较智能的感觉；

      当然他跟我讲得并不止这一点点，如申请也不应该由他们自己录入，应该是系统自动给他们生成，还有系统很多环节不应该是由人作为事件的开始点，应该由系统主动的做出判断并提醒操作人员应该做什么，还有哪些事需要做；我最后的感觉就是以前的系统只是一个单纯的工具，操作人什么时候要用就拿过来用一下；而以后的系统应该更智能，从被动的接收变为主动的提供工作上的指导，实时促进岗位上人员的工作；从被动的信息传递到主动的信息分析；

      又跑远了，本章内容是讲框架中的“消息管理”模块，当然此功能肯定没有上面说的那么神，其实就是一个简单的短消息功能，与业务系统的紧密集成，实现业务出现多岗位的时候能够实时的发送消息给对应的人员；把消息类型的管理与消息的推送封装成一个公共的模块；而消息什么生成与生成什么内容就需要深入的分析业务建立相关模型了；

1）消息管理功能清单

2）消息管理界面展示

3）消息管理业务流程与核心表

4）消息管理关键技术实现

1.消息的两种模式

  看上面两张业务流程图，模式一消息类型定义好用户角色，模式二用户自定义订阅自己的消息；模式一适合岗位非常固定的企业，消息推送按照配置好的角色就行了；模式二适合一人多岗，岗位人员比较灵活的那种，因为岗位灵活如果按照模式一的方式，那此人可能时时刻刻都会受到消息的骚扰，应该上午做这个事，那么就应该只推送这个事的消息就行了，下午就推送下午的消息；所以需要用户自己维护自己的消息接收时间和内容；

2.产生消息的统一接口

九、EnterpriseFrameWork框架基础功能之消息管理