代码改变世界

消息提示的架构演进-理论篇

2011-10-12 11:57  Virus-BeautyCode  阅读(...)  评论(...编辑  收藏

 

  项目是一个互联网应用。

  假设项目有不同的用户群体,每个用户群体的前端都是一个独立的项目,交给不同的开发人员进行开发,前端和后端的交互方式选择WebService

  在前端和后端交互的过程中,主要有两类操作:一类是查询,包括返回单个记录和返回集合两种类型的查询;一类是命令,包括添加、删除、更新,当然,一次操作也可能是几个命令的组合请求。

  第一类操作需要返回数据来显示,如果没有返回数据就会提示没有找到符合条件的数据。第二类操作,一般会影响后端的持久化数据,需要返回操作的结果,是成功还是失败,还是如何如何?

  今天讨论的消息就是这种后端返回的操作结果,关于这种类型消息的设计,主要是这种消息在前段的处理、显示的相关设计。

 

  刚开始,没有进行设计,每个项目的开发者自己设计自己的消息提示格式、提示内容和UI显示。有的人用浏览器的alert,有的人用前端框架的消息提示框,还有的在一个项目中两种提示都用了。提示的方式大都是在和后端交互,获得结果之后,new一个消息框,然后直接show出来。提示的内容也都是硬编码(在new消息框的时候,使用构造函数初始化)。

 

  当然了,刚开始大家都各自为战,加紧时间赶工期,也都没有在意这些事情。在第一个迭代周期的总结会上,大家提出了这个问题,做了个总结。发现上面的做法会带来以下一些问题。

 

  • 消息提示内容的硬编码。多个相同类型是消息(例如提示操作成功),如果变更这个类型提示的内容,需要在很多地方修改,几乎苦不堪言。
  • 消息框的初始化是散落在各个和后台交互的地方的,如果需要变更一下消息框的UI,也会造成需要多个地方的修改,已经苦不堪言了。
  • 消息的逻辑代码和UI显示代码是混合在一起的,没有分离,导致无法单元测试。

 

  对于上面的问题,大家讨论了一下,可以通过下面的重构进行改进。

  • 首先,将消息分类,方便后面的处理。
  • 对于硬编码的问题,根据类型,将相同类型的内容集中管理,达到复用和便于后期维护的作用。
  • 集中管理消息框的初始化工作,也可以方便消息框UI的变更,可以通过引入工厂模式来解决。
  • 分离消息的逻辑和UI显示代码,方便单元测试和UI的变更。
  • 建立一个消息中心,集中管理消息框的初始化,以及消息的显示。

 

  这么做的目的有以下几点:

  • 消息处理的独立
  • 消息处理的公用
  • 分离消息处理的逻辑和消息内容的UI显示
  • 消息管理的集中

 

 

  经过整理,消息大概分为下面的几类

  • 成功。正确完成一次请求。
  • 提示。在完成请求的过程中,缺少必要条件,或者是某些条件发生变化,导致不能正确完成请求。
  • 异常。在完成请求的过程中,发生了异常,包括:代码异常,网络异常等等。

 

 

   在后面的实现中,准备引入面向接口的编程,将消息中心和消息的处理接口化,方便将来的替换。消息框的初始化引入工厂模式,实现初始化的集中管理,隔离消息框(标题,提示内容,按钮,按钮的操作)和消息框UI显示,为将来的UI变更预留空间。

  今天先讨论到这里,关于实现以及代码会在后面几篇分开讲解。

  大家如果有什么更好的建议,可以在后面留言给我,感谢大家的参与!!!