Model (POJO) driven GUI framework 讨论

在框架问题上, 我们不提倡经朝三暮四, 也不提倡从一而终.


现在流行POJO, 有人甚至命名为naked bean(裸奔?), 从hibernate/spring到EJB3, 大家都在裸奔. EJB3甚至连原来厚重的大棉袄都没脱就扑通一声跳下水.

还有一个好玩的东西就是xml, 叫嚣了10年, 最终大家发现这玩意费时费力, 费神, 但是赚钱赚吆喝. 多少程序员把本来挺好的程序改成基于xml的配置, 然后使劲的调试. 这些xml客户不需要写, 最终把自己累坏了. 为什么微软的产品里面到处都是xml? 没错, 但是人家还有图形设计工具啊, xml是生成的.

Annotation作为桥梁, 可以这两个问题, 把配置写到程序里面, 让POJO(Entity)本身提供配置描述, 来驱动框架生成完整应用.

企业应用, 80%是烦人的重复的只有20%技术含量的增删改查之类的东西. 强壮的框架就是要覆盖这里无聊的部分, 几个可重载的重要组件, 甚至全部基本流程. 去掉的来源, 就是标注过的POJO.

Entity bean+JSR303可以提供: 存储/验证信息. 还需要额外定义(应该有个JSR标准):
说明: 标题/帮助/i18n
控件: dropdown还是radio
视图: 每个视图下的tab/group/order
Rule: 联动关系等 (涉及到逻辑验证)

有了标注过的POJO, 驱动出Swing/Web/CLI(命令行)都不难.

不是MDA, 是纯POJO+Annotation.

现在已有一些Modal driven的框架,大多数基于web, 少数还支持swing. 参考:[url=http://java.dzone.com/articles/automatic-user-interface]OpenXava[/url],注意后面的相关链接.

Tips:
复杂case怎么办? 扩展通用实现
Annotation太多怎么办? 把视图定义和rule独立出来, 把说明部分放到资源文件, 做个插件把bean当成表格看
还想偷懒怎么办? MVC/资源/缺省命名约束
why annotation? IDE support


每个公司都有框架的喜悦和烦恼, 欢迎大家来探讨一下.