JS界面框架的思考——控件逻辑结构与DOM的控制

  纯JS实现的Web界面框架,被认为是一种基于组件的管理方式,可以认为是在浏览器上近似实现桌面应用GUI的方式。Web组件的封装与桌面控件的实现不同,JS框架需要通过封装来做的,就是管理与其逻辑结构相关联的DOM元素;而这两者在思想上却具有相似的地方(这是一定的,因为本质上这是一种主动的模仿)。

  因此有以下几个问题需要关心:

  1. 封装必然导致的问题就是灵活性受限,提供的API不可能是完备的。用户如果跨越框架直接操纵DOM,将是非常不可靠的,框架的更新或者仅仅简单的界面风格切换,都可能导致用户的越级操作失效。因此,接口提供用户需要的尽可能多的功能,是非常必要的。
  2. 对于控件的操作,应该总是从逻辑对象入手,由框架操作DOM对象,就像Windows编程时程序员会得到控件句柄,而控件句柄永远是指向了该控件的逻辑结构所在的空间,而不是二维层缓冲区。因此,一个逻辑控件的构造与析构,与实际控件是否在缓冲区或被释放,是没有直接的联系的(对JS来说,就是与DOM对象的存在与否没有关系)。
  3. 理论上良好的实现是需要时才产生DOM,而不是在构造时就产生DOM,尽管由于浏览器的优化行为,构造一个不用显示的DOM,计算开销是比较小的,然而还是由于浏览器的优化行为(空间换时间),DOM往往必须占据不少内存空间,远大于控件逻辑对象。实际上程序员是比较习惯手动控制DOM的创建和移除,因此许多框架中程序员都需要明确向框架发出构造DOM的指示,这就要求程序员对与何时构造DOM有一个基本的考虑。
  4. 意图不明确的封装是糟糕的。如果在控件的逻辑结构上需要再进行一次封装,那么最好有明确的理由和完整的架构考虑,就像在Windows的C库上封装的MFC,甚至虚拟机。当然,使用MFC的程序员,往往不再同时直接接触Windows API,因为那样是被视为混乱的程序结构。然而在架构不明确的框架中,使用不同层次的框架往往是难免的,这样将同样产生不可靠的操作。另外,除了造成内聚性差以外,层次不明确导致开发人员也无法知道,使用哪一层的操作才是最优的,往往可能导致不同的实现,代码可读性也变差。
  5. 框架要提供必要的文档,帮助开发人员了解,对逻辑控件的操作,会如何影响用户交互。
  6. 不能够直接操纵逻辑对象的数据成员,因为直接操作数据成员一般都是不好的行为,而应该总是使用方法来进行调用,尽管JS语法上并没有可见性修饰符,但是从封装性的角度而言是不希望用户这样操作的。因此,对于可以修改的数据成员,总是应该提供修改/获取它们的值的方法。