Model (POJO) driven GUI framework 议论
日期：2014-05-20 浏览次数：21195 次
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. 参考:OpenXava,注意后面的相关链接.
Tips:
复杂case怎么办? 扩展通用实现
Annotation太多怎么办? 把视图定义和rule独立出来, 把说明部分放到资源文件, 做个插件把bean当成表格看
还想偷懒怎么办? MVC/资源/缺省命名约束
why annotation? IDE support
每个公司都有框架的喜悦和烦恼, 欢迎大家来探讨一下.
现在的不少框架和组件，都是以解释型为主， 这种用很精炼的语言描述就能实现一个很强的功能界面
但是这种会有几个问题
1. 会java 的人不会在这种框架下写代码
2. 出现问题不会修改。因为pojo上的描述语言是由另一个解析器分析后才变为一个强大的功能界面，所以解析器里大部是共性抽象的代码.
可能因为所在的公司性质不同有关，我们的员工都是1年半~2年为一个周期轮换
所以我们的要求是让会用java 的人，就能在框架上写代码
框架给我们的帮助是写的增删改查之类功能，是在填空，而不是在从头开始句
每个公司都会有固化的几套业务。 这些业务的模式都是一样的，可能每个模式里只要换几个关键参数就可以。
所以框架就是要把业务的流程都生成出来，再由程序员去填空。
当然这些流程不是一个个精炼的描述语言，而是实现的代码。懂java 就能看得懂的代码。没有解析器，有什么不爽就直接修改。
现在的不少框架和组件，都是以解释型为主， 这种用很精炼的语言描述就能实现一个很强的功能界面
但是这种会有几个问题
1. 会java 的人不会在这种框架下写代码
2. 出现问题不会修改。因为pojo上的描述语言是由另一个解析器分析后才变为一个强大的功能界面，所以解析器里大部是共性抽象的代码.
可能因为所在的公司性质不同有关，我们的员工都是1年半~2年为一个周期轮换
所以我们的要求是让会用java 的人，就能在框架上写代码
框架给我们的帮助是写的增删改查之类功能，是在填空，而不是在从头开始句
每个公司都会有固化的几套业务。 这些业务的模式都是一样的，可能每个模式里只要换几个关键参数就可以。
所以框架就是要把业务的流程都生成出来，再由程序员去填空。
当然这些流程不是一个个精炼的描述语言，而是实现的代码。懂java 就能看得懂的代码。没有解析器，有什么不爽就直接修改。
小朱真是精打细算，对于流动性很强的公司确实最直观就好。
生成的代码将来横向重构会有问题，对于维护期不长的也无所谓了。
ROR也是生成代码。
偶想是用一框架驱动出各种组件，包括一个字段，用在wizard中的一个小画面，带字段level验证，带外键对象的链接（像sap)，可大可小，可以灵活组装应用。
能不能晒晒你的山寨标记和思路？大家遵循同一山寨标准以后可以用标准model直接比较框架来～。
能不能晒晒你的山寨标记和思路？大家遵循同一山寨标准以后可以用标准model直接比较框架来～。
那我就献丑了，以下是我的基本思路：
1 类型映射。 ORM里，对象类型和数据的字段类型做映射，比如string -> varchar;同理，在OUM里，string -> textbox;其他以此类推。
2 实体映射。 实体有各种属性，自动生成的界面里就通过反射把属性都列举出来，再根据类型映射生成界面。
3 方法映射。 方法有很多参数，也是根据参数的类型映射成界面组件。
4 对象映射。 以service 层对象为例，一般是单例，比如int Calculator.add(int x,int y)。对象名字就是一级菜单的名字，方法名作为其下的菜单项。返回值也可以在界面上输出。
有兴趣的话，我等下上个截屏给大家看看。
那我就献丑了，以下是我的基本思路：
1 类型映射。 ORM里，对象类型和数据的字段类型做映射，比如string -> varchar;同理，在OUM里，string -> textbox;其他以此类推。
2 实体映射。 实体有各种属性，自动生成的界面里就通过反射把属性都列举出来，再根据类型映射生成界面。
3 方法映射。 方法有很多参数，也是根据参数的类型映射成界面组件。
4 对象映射。 以service 层对象为例，一般是单例，比如int Calculator.add(int x,int y)。对象名字就是一级菜单的名字，方法名作为其下的菜单项。返回值也可以在界面上输出。
有兴趣的话，我等下上个截屏给大家看看。
很有兴趣! 有图有真相!
3/4方法映射很有趣, 应该很实用, 解决了怎样生成菜单项的action问题.
但是各种标记要在方法参数上, 有些标记不知道有没有限制.
另外向导问题能解决吗? 向导比较复杂.
那我就献丑了，以下是我的基本思路：
1 类型映射。 ORM里，对象类型和数据的字段类型做映射，比如string -> varchar;同理，在OUM里，string -> textbox;其他以此类推。
2 实体映射。 实体有各种属性，自动生成的界面里就通过反射把属性都列举出来，再根据类型映射生成界面。
3 方法映射。 方法有很多参数，也是根据参数的类型映射成界面组件。
4 对象映射。 以service 层对象为例，一般是单例，比如int Calculator.add(int x,int y)。对象名字就是一级菜单的名字，方法名作为其下的菜单项。返回值也可以在界面上输出。
有兴趣的话，我等下上个截屏给大家看看。
很有兴趣! 有图有真相!
3/4方法映射很有趣, 应该很实用, 解决了怎样生成菜单项的action问题.
但是各种标记要在方法参数上, 有些标记不知道有没有限制.
另外向导问题能解决吗? 向导比较复杂.
我也很有兴趣，现在对繁杂的页面，已经很烦了。
在框架问题上, 我们不提倡经朝三暮四, 也不提倡从一而终.
现在流行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. 参考:OpenXava,注意后面的相关链接.
Tips:
复杂case怎么办? 扩展通用实现
Annotation太多怎么办? 把视图定义和rule独立出来, 把说明部分放到资源文件, 做个插件把bean当成表格看
还想偷懒怎么办? MVC/资源/缺省命名约束
why annotation? IDE support
每个公司都有框架的喜悦和烦恼, 欢迎大家来探讨一下.
1 楼
carlkkx
2009-12-16
呵呵，你这个东西要是支持类似FieldMap这样的数据结构就好了。
http://www.iteye.com/topic/534249
我已经搞了一些诸如FieldMapSetTable，FieldMapFormBinder之类的东西，当然你这个直接从数据模型生成界面，自动化倒是很自动化了，但是界面如果不满足需求呢？还有一个数据过来可能只是某些栏位需要表现为GUI，这些东西还是要手动定义吧？有些还是逃不掉吧？
http://www.iteye.com/topic/534249
我已经搞了一些诸如FieldMapSetTable，FieldMapFormBinder之类的东西，当然你这个直接从数据模型生成界面，自动化倒是很自动化了，但是界面如果不满足需求呢？还有一个数据过来可能只是某些栏位需要表现为GUI，这些东西还是要手动定义吧？有些还是逃不掉吧？
2 楼
steeven
2009-12-16
兄弟比我还晚，PFPF.
关于视图上的栏位定义，肯定会有些在界面上不用的。在JPA里面不用的用@Transient标注，在完全的缺省定义里面用@Invisible标注也可以。在OpenXava里面是这样定义的：
OX的方法比较紧凑，但是重构的时候容易出错，我个人觉得可以用字段名常量去增强一下，另外视图最好用单独类来表示，因为和视图相关的东西比较多。当然，这玩意是复杂情况采用的。命名上固定用Xxx$View就可以找到了。
对于简单界面，new MdaGui(pojo), 这是个通用实现。
对于复杂界面，MyXxxGui extends MdaGui{这里去重载，增加一些特殊实现}
上班忙，有空再研究你的方案～谢谢
关于视图上的栏位定义，肯定会有些在界面上不用的。在JPA里面不用的用@Transient标注，在完全的缺省定义里面用@Invisible标注也可以。在OpenXava里面是这样定义的：
@View( // 2
members=
"year, number, date;" +
"comment;" +
"customer { customer }" +
"details { details }" +
"amounts { amountsSum; vatPercentage; vat }" +
"deliveries { deliveries }"
)
public class Invoice {...}OX的方法比较紧凑，但是重构的时候容易出错，我个人觉得可以用字段名常量去增强一下，另外视图最好用单独类来表示，因为和视图相关的东西比较多。当然，这玩意是复杂情况采用的。命名上固定用Xxx$View就可以找到了。
对于简单界面，new MdaGui(pojo), 这是个通用实现。
对于复杂界面，MyXxxGui extends MdaGui{这里去重载，增加一些特殊实现}
上班忙，有空再研究你的方案～谢谢
3 楼
steeven
2009-12-16
如果将来有了UI Annotation标准, 就像JPA一样, 对象定义不动, 换个框架, 就能换个UI, 不管是web还是swing还是flash, 甚至多种风格同时存在. 太容易了. 量产
4 楼
zhufanamo
2009-12-16
现在的不少框架和组件，都是以解释型为主， 这种用很精炼的语言描述就能实现一个很强的功能界面
但是这种会有几个问题
1. 会java 的人不会在这种框架下写代码
2. 出现问题不会修改。因为pojo上的描述语言是由另一个解析器分析后才变为一个强大的功能界面，所以解析器里大部是共性抽象的代码.
可能因为所在的公司性质不同有关，我们的员工都是1年半~2年为一个周期轮换
所以我们的要求是让会用java 的人，就能在框架上写代码
框架给我们的帮助是写的增删改查之类功能，是在填空，而不是在从头开始句
每个公司都会有固化的几套业务。 这些业务的模式都是一样的，可能每个模式里只要换几个关键参数就可以。
所以框架就是要把业务的流程都生成出来，再由程序员去填空。
当然这些流程不是一个个精炼的描述语言，而是实现的代码。懂java 就能看得懂的代码。没有解析器，有什么不爽就直接修改。
5 楼
hatedance
2009-12-17
我对这个也很有兴趣，我管它叫OUM,借用ORM的思路，OUM就是Object UI Mapping.
目前我自制的山寨货能支持Swing和HTML2种实现。
目前我自制的山寨货能支持Swing和HTML2种实现。
6 楼
steeven
2009-12-17
zhufanamo 写道
现在的不少框架和组件，都是以解释型为主， 这种用很精炼的语言描述就能实现一个很强的功能界面
但是这种会有几个问题
1. 会java 的人不会在这种框架下写代码
2. 出现问题不会修改。因为pojo上的描述语言是由另一个解析器分析后才变为一个强大的功能界面，所以解析器里大部是共性抽象的代码.
可能因为所在的公司性质不同有关，我们的员工都是1年半~2年为一个周期轮换
所以我们的要求是让会用java 的人，就能在框架上写代码
框架给我们的帮助是写的增删改查之类功能，是在填空，而不是在从头开始句
每个公司都会有固化的几套业务。 这些业务的模式都是一样的，可能每个模式里只要换几个关键参数就可以。
所以框架就是要把业务的流程都生成出来，再由程序员去填空。
当然这些流程不是一个个精炼的描述语言，而是实现的代码。懂java 就能看得懂的代码。没有解析器，有什么不爽就直接修改。
小朱真是精打细算，对于流动性很强的公司确实最直观就好。
生成的代码将来横向重构会有问题，对于维护期不长的也无所谓了。
ROR也是生成代码。
偶想是用一框架驱动出各种组件，包括一个字段，用在wizard中的一个小画面，带字段level验证，带外键对象的链接（像sap)，可大可小，可以灵活组装应用。
7 楼
steeven
2009-12-17
hatedance 写道
我对这个也很有兴趣，我管它叫OUM,借用ORM的思路，OUM就是Object UI Mapping.
目前我自制的山寨货能支持Swing和HTML2种实现。
目前我自制的山寨货能支持Swing和HTML2种实现。
能不能晒晒你的山寨标记和思路？大家遵循同一山寨标准以后可以用标准model直接比较框架来～。
8 楼
hatedance
2009-12-17
steeven 写道
hatedance 写道
我对这个也很有兴趣，我管它叫OUM,借用ORM的思路，OUM就是Object UI Mapping.
目前我自制的山寨货能支持Swing和HTML2种实现。
目前我自制的山寨货能支持Swing和HTML2种实现。
能不能晒晒你的山寨标记和思路？大家遵循同一山寨标准以后可以用标准model直接比较框架来～。
那我就献丑了，以下是我的基本思路：
1 类型映射。 ORM里，对象类型和数据的字段类型做映射，比如string -> varchar;同理，在OUM里，string -> textbox;其他以此类推。
2 实体映射。 实体有各种属性，自动生成的界面里就通过反射把属性都列举出来，再根据类型映射生成界面。
3 方法映射。 方法有很多参数，也是根据参数的类型映射成界面组件。
4 对象映射。 以service 层对象为例，一般是单例，比如int Calculator.add(int x,int y)。对象名字就是一级菜单的名字，方法名作为其下的菜单项。返回值也可以在界面上输出。
有兴趣的话，我等下上个截屏给大家看看。
9 楼
steeven
2009-12-17
hatedance 写道
那我就献丑了，以下是我的基本思路：
1 类型映射。 ORM里，对象类型和数据的字段类型做映射，比如string -> varchar;同理，在OUM里，string -> textbox;其他以此类推。
2 实体映射。 实体有各种属性，自动生成的界面里就通过反射把属性都列举出来，再根据类型映射生成界面。
3 方法映射。 方法有很多参数，也是根据参数的类型映射成界面组件。
4 对象映射。 以service 层对象为例，一般是单例，比如int Calculator.add(int x,int y)。对象名字就是一级菜单的名字，方法名作为其下的菜单项。返回值也可以在界面上输出。
有兴趣的话，我等下上个截屏给大家看看。
很有兴趣! 有图有真相!
3/4方法映射很有趣, 应该很实用, 解决了怎样生成菜单项的action问题.
但是各种标记要在方法参数上, 有些标记不知道有没有限制.
另外向导问题能解决吗? 向导比较复杂.
10 楼
icefire
2009-12-18
steeven 写道
hatedance 写道
那我就献丑了，以下是我的基本思路：
1 类型映射。 ORM里，对象类型和数据的字段类型做映射，比如string -> varchar;同理，在OUM里，string -> textbox;其他以此类推。
2 实体映射。 实体有各种属性，自动生成的界面里就通过反射把属性都列举出来，再根据类型映射生成界面。
3 方法映射。 方法有很多参数，也是根据参数的类型映射成界面组件。
4 对象映射。 以service 层对象为例，一般是单例，比如int Calculator.add(int x,int y)。对象名字就是一级菜单的名字，方法名作为其下的菜单项。返回值也可以在界面上输出。
有兴趣的话，我等下上个截屏给大家看看。
很有兴趣! 有图有真相!
3/4方法映射很有趣, 应该很实用, 解决了怎样生成菜单项的action问题.
但是各种标记要在方法参数上, 有些标记不知道有没有限制.
另外向导问题能解决吗? 向导比较复杂.
我也很有兴趣，现在对繁杂的页面，已经很烦了。
11 楼
hatedance
2009-12-18
做了段演示，这个轮子还很毛糙，我对swing也不熟，不要见怪，大家看个意思。希望flash能播放。
基本上实现起来也不麻烦，就是根据反射，得到所需的信息，来生成界面。多数额外的信息都是用annotation提供的。
只要在service类里加一个方法，就会生成对应的菜单项。
每个界面都有一个submit按钮，也是用反射去invoke对应的方法。
这种自动生成的界面，只适用简单的需求。但对付大多数企业应用，特别是CRUD是很好的。
欢迎拍砖！
基本上实现起来也不麻烦，就是根据反射，得到所需的信息，来生成界面。多数额外的信息都是用annotation提供的。
只要在service类里加一个方法，就会生成对应的菜单项。
每个界面都有一个submit按钮，也是用反射去invoke对应的方法。
这种自动生成的界面，只适用简单的需求。但对付大多数企业应用，特别是CRUD是很好的。
欢迎拍砖！
12 楼
steeven
2009-12-18
很好很强大～ 上班中，晚上回去研究。
我记得SAP里面的对象间引用，显示名字，旁边有"..."进入选择/维护界面。
我记得SAP里面的对象间引用，显示名字，旁边有"..."进入选择/维护界面。
13 楼
steeven
2009-12-28
对不起,最近有很多问题要忙,稍后分解.
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
