消息提示的架构演进-理论篇
本文转自 virusswb 51CTO博客，原文链接：http://blog.51cto.com/virusswb/685995，如需转载请自行联系原作者项目是一个互联网应用。
假设项目有不同的用户群体，每个用户群体的前端都是一个独立的项目，交给不同的开发人员进行开发，前端和后端的交互方式选择
WebService
。
在前端和后端交互的过程中，主要有两类操作：一类是查询，包括返回单个记录和返回集合两种类型的查询；一类是命令，包括添加、删除、更新，当然，一次操作也可能是几个命令的组合请求。
第一类操作需要返回数据来显示，如果没有返回数据就会提示没有找到符合条件的数据。第二类操作，一般会影响后端的持久化数据，需要返回操作的结果，是成功还是失败，还是如何如何？
今天讨论的消息就是这种后端返回的操作结果，关于这种类型消息的设计，主要是这种消息在前段的处理、显示的相关设计。
刚开始，没有进行设计，每个项目的开发者自己设计自己的消息提示格式、提示内容和
UI
显示。有的人用浏览器的
alert
，有的人用前端框架的消息提示框，还有的在一个项目中两种提示都用了。提示的方式大都是在和后端交互，获得结果之后，
new
一个消息框，然后直接
show
出来。提示的内容也都是硬编码（在
new
消息框的时候，使用构造函数初始化）。
当然了，刚开始大家都各自为战，加紧时间赶工期，也都没有在意这些事情。在第一个迭代周期的总结会上，大家提出了这个问题，做了个总结。发现上面的做法会带来以下一些问题。
- 消息提示内容的硬编码。多个相同类型是消息（例如提示操作成功），如果变更这个类型提示的内容，需要在很多地方修改，几乎苦不堪言。
- 消息框的初始化是散落在各个和后台交互的地方的，如果需要变更一下消息框的UI，也会造成需要多个地方的修改，已经苦不堪言了。
- 消息的逻辑代码和UI显示代码是混合在一起的，没有分离，导致无法单元测试。
对于上面的问题，大家讨论了一下，可以通过下面的重构进行改进。
- 首先，将消息分类，方便后面的处理。
- 对于硬编码的问题，根据类型，将相同类型的内容集中管理，达到复用和便于后期维护的作用。
- 集中管理消息框的初始化工作，也可以方便消息框UI的变更，可以通过引入工厂模式来解决。
- 分离消息的逻辑和UI显示代码，方便单元测试和UI的变更。
- 建立一个消息中心，集中管理消息框的初始化，以及消息的显示。
这么做的目的有以下几点：
- 消息处理的独立
- 消息处理的公用
- 分离消息处理的逻辑和消息内容的UI显示
- 消息管理的集中
经过整理，消息大概分为下面的几类
- 成功。正确完成一次请求。
- 提示。在完成请求的过程中，缺少必要条件，或者是某些条件发生变化，导致不能正确完成请求。
- 异常。在完成请求的过程中，发生了异常，包括：代码异常，网络异常等等。
在后面的实现中，准备引入面向接口的编程，将消息中心和消息的处理接口化，方便将来的替换。消息框的初始化引入工厂模式，实现初始化的集中管理，隔离消息框（标题，提示内容，按钮，按钮的操作）和消息框UI显示，为将来的UI变更预留空间。
今天先讨论到这里，关于实现以及代码会在后面几篇分开讲解。
大家如果有什么更好的建议，可以在后面留言给我，感谢大家的参与！！！
