界面组件设计注意点

这是我在公司产品的界面框架设计讨论建议中的一节，项目是JAVA的，但界面组件的思想是通用的，也借鉴了不少.NET的WEB FORM要素。没时间就不作修改直接贴在这里了，虽然凌乱，但或许能有些帮助。
界面组件
其实不单是界面组件,包括界面组件,Portlet(如果有PORTAL),公共组件,模板类库,公共方法等等,.本质上就是所有可重用组件化模块化的代码的抽象,为减少工程师的重复劳动,提高代码复用,并实现统一管理.

组件化代码抽象工作在技术上不是大问题,难度主要是在管理上.如何良好规划把握抽象程度,统一维护管理,推进和运用,实现质量的保证等,是界面组件抽象工作真正成功与否的重点,.这就要涉及到项目管理和研发管理了,不展开了.

谈谈主角-界面组件的一些重点.在界面组件的设计主要是从以下几方面设计

操作处理

界面组件的交互操作处理是界面操作的一个重要组成部分,也是非常麻烦的工作.首先要确定各组件的操作处理程序是在客户端还是服务器端实现.一个比较好的建议是,将尽量多的处理程序放在服务器端,原因一是这样可以实现高度的对象化,使程序的结构和层次更清晰;原因二是由于目前仍然没有功能强大且结构规范合理的客户端脚本语言,在服务器端编程仍然是最方便和有效的.当然,服务器端操作处理的弊端也有不少,对于简单操作增加了设计复杂度甚至是使用时的工作量,增加了服务器端的负担.

简单的来说,将客户端的界面操作处理封装在服务器端的实现思想就是,用HTML和JS等客户端脚本捕捉客户端对象动作,并使用隐藏域(以及自己的数据信息编码)封装这些信息,在服务器端建立相关的映射并处理得到的信息,在最终响应时解释并生成相应的客户端代码. 难点在于组件事件和属性与服务器端处理方法的映射和解释的准确性.

对于复杂的界面组件(尤其是数据逻辑不同时),设计人员对于操作响应将难以设计与控制(因为都将涉及到具体的数据逻辑),对于使用人员,仍将陷入复杂的JS梦魇中.

将尽量多的操作处理放在服务器端(当然最好也能提供客户端处理的入口),这是一个建议的准则,但并不绝对.例如用户输入验证处理,除非要做详细的记录与分析或者将其包含进整个错误处理框架中,否则不建议做成单独的验证器控件,还是建议在客户端进行处理.在整个界面组件的设计中会碰到很多类似的操作处理层次与粒度的把握,这也是工作的一个难点与重点.

组件数据源

大部分的界面组件都有其所属的数据,并将其呈现.例如我们常用的表格,其数据源一般就是一个二维表;一个下拉菜单,其数据源一般就是一个键值对.对于数据组件,设计时,数据绑定是一个重点.对于组件的使用者,他提交的应该是一个数据结构对象,而不是最终要表现的数据(当然也应该提供一些简单的由使用者直接输入的数据绑定).这是实现表现层与逻辑层分离的一个重要条件,还会带来很多方面的好处,例如在数据源合法性的检测,数据源的更新操作处理等等.

对于我们这样一个复杂的系统来说,数据绑定的设计不建议与底层数据源建立关系,中间应设立一组数据源对象.

组件容器的复合性

部分组件应具有容器性,可以实现对其他组件的包含.实现容器组件时,就一定会实现组件树.除了一般组件要考虑的问题外,对于组件树中的组件,事件传递(复杂的组件容器,还要考虑异步响应和事件保存),样式布局是最基本的两点.而在实现方面,选择怎样的模式和实现方法,也要根据自己的需求来权衡.

无论是打算以struts的taglib或者模块化的JS或者是其他框架(例如某Portal中的Portlet)中的表达语言实现界面组件,都要从以上3点作为立足点来进行界面组件的设计,这是实现对象化,表示层逻辑层分离,实现代码复用,工作划分清晰的必经之路.当然在具体框架中实现肯定会受到一定的限制,甚至无法实现.

界面组件的设计还要考虑

n        所有组件的生命周期规划

n        组件范围

n        组件的属性与状态管理

n        组件的MVC结构实现(与整个界面框架的MVC结构统一)

n        组件事件的缓存与并发性

n        组件安全性

一个良好的界面组件设计这些方面都有很高的要求,不过我觉得对于我们产品来说,这些都可以简单考虑,只要实现基本需求和满足以上三点(尤其是操作处理上对这些设计的要求与依赖比较高)的实现即可.

界面组件的设计可以参考JSF或者.NET的web forms,JAVA社区里这方面研究现在也是一个大热点.

          
PS：由于现在参与的项目已放弃.NET，所以我在.NET方面的使用与研究暂时停顿下来。当然软件的思想是相同的，所以对于一些自认为有价值的东西会贴一些上来，不过不再做有针对性的整理与修改。