企业应用UI开发模式

今天和老板吃饭，谈到开发效率的问题。老板提议能否用一些网页设计工具来做ui开发，原因是他见到有的developer花费很多时间在写ui上面。老板认为如果做ui能直接拖拽控件，所见即所得，这样就可以把主要精力花在核心业务上面。老板本身是做业务的，博士出身，但是基本不懂软件开发。估计是平时看我用rose做设计觉得不错，才冒出这样的想法。

 

首先大概介绍一下我们公司的系统。我们是做制造业的生产管理系统，主要客户是模具制造，机器制造，印刷等行业的公司。我们只有一个产品，销售给不同公司的时候针对客户的一些特殊需求做一些定制。架构上用的是jsp+struts+ejb+oracle。系统复杂程度中等偏上，有四十多个业务模块，persistent object大概有近千个。

 

在显示层，大量使用了javascript/ajax，css。因为客户对界面user friendly要求很高，所以我们的界面很复杂，不是简单的单个object的crud。我开发了不少ajax-enabled ui controls，例如tree, grid table, split panel, tab panel, modal popup window, auto suggest（注：并非重新发明轮子，只是我做这些的时候ajax刚刚流行，很多现在牛b的框架都还没有出现，出现的也还不是很完善）。为了让其他developer能轻松的使用这些ui控件，我又写一系列的jsp tag。这些jsp tag的主要作用，一是封装了底层的javascript, css细节，二是负责和web层数据绑定，数据交互，以及和后台的xml配置（主要用于描述静态业务数据）绑定，三是自动进行数据验证。

 

好了，言归正传。我给老板的回答是：

 

1。基于目前的ui复杂性，90%都不是原生的html控件。如果用一般的网页设计工具，比如dreamweaver，frontpage这种，除了画一些整体的布局以外，似乎没有太大的其他用途。如果用dreamweaver来设计具体的页面，那样就无法使用现成的jsp tag，developer需要花费更多的时间来实现原先tag封装的复杂功能。

 

2。一些ide，都提供可视化开发jsp的功能。比如说eclipse, netbean, jdevelper。但他们提供的大部分也是原生的html control，复杂一点的会提供内置ajax功能的jsf facelet。但都不能满足我们的需求。

 

3。如果使用工具开发界面的话，工具必须能供提供扩展性。这样我或许可以用plugin的形式把自己封装过的ui控件加入到工具中，继而以拖拽的方法来“画“界面。否则虽然工具简化了layout的开发，但却大大复杂化了数据绑定，交互等其他方面。

 

4。有的developer做ui慢，是因为他不求甚解，不做研究，对javascript，css，html不熟。有些已经提供的功能都不知道用。对于这样的人，就算ui简单了，后台逻辑还是能累死他。

 

想和大家讨论的是：

 

A。对于企业系统，我很想知道其他公司表现层都是用什么样的开发模式？单靠美工mm可以搞定吗？我们公司根本就没有专门的美工，界面都是developer做的。

 

B。可视化开发能否真的提高开发效率？还是看起来很美，实际上用处不大？其实我个人总是感觉，可视化编辑器拽出来的代码都很龌龊。

 

C。有没有符合能符合我需求的可视界面工具？我感觉可以通过为ide开发一些插件来做到这一点，不知道是否可行？

 

欢迎大家指点，以及拍砖。

评论

45 楼 rain2005 2010-03-12  

现在的现实是真正懂js,css,html的开发人员太少了，我见过太多的程序员把页面写的太复杂就是因为不懂css,html。

可视化开发对于web来说基本没有什么用。

44 楼 weihong01267 2010-03-12  

开发出来了 是否开源 一下下  啊 哈哈

43 楼 抛出异常的爱 2009-12-29  

jamiesun 写道

引用

4。有的developer做ui慢，是因为他不求甚解，不做研究，对javascript，css，html不熟。有些已经提供的功能都不知道用。对于这样的人，就算ui简单了，后台逻辑还是能累死他。

对于一个熟手来说，无论是用工具还是手工编码做界面，都不是问题，一个熟手会合理的利用工具。
与其在这个问题上伤脑筋，不如下点功夫培训一下这些生手，不要指望用工具去迁就他们。
在此c/s时代一个程序员不屑于html，js之类，这很正常；但b/s时代，对于html，js还是一知半解不屑于学习的程序员，应该为此感到羞愧。

社会化分工就是要减少熟手的养成时间.
流水线的产生目的是提高劳动效率.

发明这两种方法的人是白痴.
因为只要多雇几个裁缝
就把所有事都搞定了.

42 楼 logicgate 2009-07-15  

timshaw9791 写道

tomxh001 写道

其实一些大的厂商早实现可视化web ui开发了，比如ibm、oracle，可惜他们工具都不对外开放
国内金蝶好像也有自己的一套开发模式

感觉现在可视化开发一个是标准不完善、再就是没有个好的ide支持，如果ide足够强大能够自动维护代码和设计，很多问题就解决了

金蝶有自己的IDE,基于eclipse的BOSStudio，这个太庞大了，不是几杆枪一时半会儿能搞出来的，是个囊括整个软件生命周期的IDE。
另外他们用BOSStudio拖拽出来的界面是Swing，EAS的界面总体感觉还是可以的，这个基于Swing的界面框架其实思路倒是很清晰，就是受制于向后兼容性所以搞得很庞大。如果借用他的理念从头再搞一个，我觉得应该是非常了不得的东东

看了一些金蝶bos的资料，很好很强大，也非常符合我的构想。不过这个东东的确不是一时半会能搞出来的。

金蝶也算是我们公司的竞争者了，我老板前面几个月一直才谈一个挺大的公司的项目，结果最后被金蝶抢去了。

有谁知道ibm, oracle, sap, microsoft这些公司内部都有什么类似的开发工具吗？

41 楼 jamiesun 2009-07-13  

javascript不是想象中的那么BT，为什么很多程序员不愿意去接触它，我觉得还是一种观念上的转变比较难。

以前不少程序员是从做网站起家的，到了后来开始正二八经的做企业开发，对于BS架构的应用自然都能驾轻就熟。


而现在，大部分程序员一毕业便进入公司开始做企业应用，对于javascript,html基本没有一点概念，我们公司招了一批应届生，其中没有一个熟悉javascript，html的，而且总是有意无意的去避开html和js。


观念要转变，技能要熟练。

40 楼 timshaw9791 2009-07-13  

jamiesun 写道

引用

4。有的developer做ui慢，是因为他不求甚解，不做研究，对javascript，css，html不熟。有些已经提供的功能都不知道用。对于这样的人，就算ui简单了，后台逻辑还是能累死他。

对于一个熟手来说，无论是用工具还是手工编码做界面，都不是问题，一个熟手会合理的利用工具。

与其在这个问题上伤脑筋，不如下点功夫培训一下这些生手，不要指望用工具去迁就他们。

在此c/s时代一个程序员不屑于html，js之类，这很正常；但b/s时代，对于html，js还是一知半解不屑于学习的程序员，应该为此感到羞愧。

我羞愧一下先-_-b，不过我仍然恬不知耻的不想进一步学习js。也不想学习特定于某个浏览器的html和css，因为我我觉得企业应用(Application,相对于面相大众的site)假设在html+js上有点不划算。
既然我定位在搞企业应用而不是搞面向大众的网站，我没有学习进一步学习他们的必要
回想一下，最初C/S往B/S迁，主要有两个原因：
1.部署升级方便
2.可访问性

但是人们发现B/S做Application动态性不够，于是js之类的就出现了，长长的一条路啊。
但是正如第一页的一朋友所说：现今应用的需求已经大大超出了html+js能够承载的范围，再加上html+js这些标准经常被当成皮球踢来踢去，甚至是这种妥协交易的产物。在这样的html+js上创建Applicatoin(而不是site)才是我们痛苦的根源，所以我们可以看到Web框架城头变幻大王旗你方唱罢我登场，框架数都数不过来；另一方我们还能看见市面上充斥着html & javascript的hack & trick的书籍。

其实回过头来，可以看看当初在Application方面B/S取代C/S的两个初衷就可以发现，完全可以来一个釜底抽薪。
作为企业应用，大体上环境都是可控的，给每个客户端flash很难么。。。装银光很难么，还有AIR的那种部署方式你不觉得很自然很轻松么。

对于Ajax，我的态度是敬而远之，我佩服那些码js的人，因为我觉得他们在ide很操蛋的情况下码出了一堆一堆的js真的很了不起，这方便我完全寸步难行。但我更相信，他们有这样的精神，如果恰好又是搞企业应用，把精力放在正宗RIA应该是能打出大大的一番天地的。

39 楼 timshaw9791 2009-07-12  

tomxh001 写道

其实一些大的厂商早实现可视化web ui开发了，比如ibm、oracle，可惜他们工具都不对外开放
国内金蝶好像也有自己的一套开发模式

感觉现在可视化开发一个是标准不完善、再就是没有个好的ide支持，如果ide足够强大能够自动维护代码和设计，很多问题就解决了

金蝶有自己的IDE,基于eclipse的BOSStudio，这个太庞大了，不是几杆枪一时半会儿能搞出来的，是个囊括整个软件生命周期的IDE。
另外他们用BOSStudio拖拽出来的界面是Swing，EAS的界面总体感觉还是可以的，这个基于Swing的界面框架其实思路倒是很清晰，就是受制于向后兼容性所以搞得很庞大。如果借用他的理念从头再搞一个，我觉得应该是非常了不得的东东

38 楼 jamiesun 2009-07-10  

引用

4。有的developer做ui慢，是因为他不求甚解，不做研究，对javascript，css，html不熟。有些已经提供的功能都不知道用。对于这样的人，就算ui简单了，后台逻辑还是能累死他。

对于一个熟手来说，无论是用工具还是手工编码做界面，都不是问题，一个熟手会合理的利用工具。

与其在这个问题上伤脑筋，不如下点功夫培训一下这些生手，不要指望用工具去迁就他们。

在此c/s时代一个程序员不屑于html，js之类，这很正常；但b/s时代，对于html，js还是一知半解不屑于学习的程序员，应该为此感到羞愧。

37 楼 fangwei 2009-07-10  

liujunsong 写道

话说回来,上面的方案都有问题,那怎么办?怎么样才能彻底摆脱对外部产品的依赖?
我的看法是,如果要真正解决这个问题,就必须下决心一切从头开始,自己开发一套控件库,通过直接访问操作系统的方式,来完成界面的渲染工作.这样一来,才能摆脱浏览器升级的麻烦.
具体来说,就是需要做如下的工作:
1.自己定义界面的ui元素定义
2.自己定义一套界面的定义格式(由ui元素组成)
3.(核心)自己开发一个界面的渲染器,将界面定义直接渲染成图形界面,采用Activex形式嵌入到IE浏览器执行.

请问要是非IE浏览器不支持ActiveX怎么办？
非常欣赏你的胆识，但是我还是认为有现成的开嘛不用，一切从头开始不如在开源代码基础上修改。

36 楼 tomxh001 2009-06-04  

其实一些大的厂商早实现可视化web ui开发了，比如ibm、oracle，可惜他们工具都不对外开放
国内金蝶好像也有自己的一套开发模式

感觉现在可视化开发一个是标准不完善、再就是没有个好的ide支持，如果ide足够强大能够自动维护代码和设计，很多问题就解决了

35 楼 Dreamer 2009-06-03  

不看好可视化Web UI开发，因为：
1. 不够灵活；
2. 一旦代码和UI设计器不同步，维护成本就会非常高。

除了老老实实写代码，还没想出好的替代方案。

34 楼 xo_tobacoo 2009-06-03  

flash不满好吗！直接画，后台用java

33 楼 liujunsong 2009-06-02  

引用

采用Activex形式嵌入到IE浏览器执行

这就有点不对了。既然不能受制于人，怎么又可以把你的核心建立在activeX，ie和windows上呢？你自己说的，“那就是把自己产品的生命,完全交代给另外一方来控制,一旦这个基础结构(Jdk/Ie/Flash)变化升级,或者有了bug,应用本身将发生无法预测的情况.”

你的控件库难道只支持ie浏览器？只支持windows？

引用

这个就不深入开展了,和上面所面临的问题都是一样的.它把Browser的问题回避了,把jdk的问题取而代之.

其实你所作的，和上面所面临的问题都是一样的。你把简单的问题都回避了，用更加复杂得多的问题取而代之。

能追求完全技术独立性的公司，恐怕全世界加起来也没有几家。ibm虽然有自己的jdk，但还是基于java规范。微软虽然有自己的操作系统，但还是基于其他公司的cpu。你所追求的，只能说是一个乌托邦式的理想。

----------------------------------------------------------------------------------
在IE浏览器里面,以ActiveX形式嵌入运行;如果是Firefox,以它支持的插件方式嵌入执行.原理是一样的.
控件库能够完整支持IE和Windows,对于一个公司产品来说已经是足够好的了.举例:Adobe flash player.

之所以要回避Browser,Jdk,javascript这些东西,主要的原因是这些软件升级的太频繁了,每次升级以后,在上面搭建的应用都需要测试兼容性.这种毫无附加值的工作会把所有的时间全部占掉,成本太高.
相对而言,os系列是相对稳定的,ms的操作系统虽然在升级,底层的API是相对稳定很多的.os升级带来的API变化虽然不能说绝对没有,但绝对比jdk,javascript的变化要小的多.
至于操作系统和cpu的关系就更加明确了,cpu的升级带来的只是速度和性能的提升,本身的机器语言并没有很大变化.正因为cpu的机器语言没有变化,升级cpu不换操作系统才是可能的;可是jdk,IE,javascript每次升级,调用接口都会有很大的变化.
所以说,基于cpu的机器语言开发,是最稳定的;基于os提供的API开发,相对差一点;基于IE,Jdk,Javascript开发,基础的稳定性就要差很多很多了.

32 楼 logicgate 2009-06-02  

liujunsong 写道

继续凑凑热闹,谈谈对ui开发的一些看法.

完全不敢苟同你的看法。

引用

底层技术,是绝对不能受制于人的

按你的说法，jdk是底层，计算机语言算不算底层，那么操作系统算不算底层，cpu算不算底层。那么所有的公司做应用的时候，是不是都应该从先开发cpu，再开发os，然后jdk？而且每个公司都有自己的一套东西，不然，就受制于人了。

引用

采用Activex形式嵌入到IE浏览器执行

这就有点不对了。既然不能受制于人，怎么又可以把你的核心建立在activeX，ie和windows上呢？你自己说的，“那就是把自己产品的生命,完全交代给另外一方来控制,一旦这个基础结构(Jdk/Ie/Flash)变化升级,或者有了bug,应用本身将发生无法预测的情况.”

你的控件库难道只支持ie浏览器？只支持windows？

引用

这个就不深入开展了,和上面所面临的问题都是一样的.它把Browser的问题回避了,把jdk的问题取而代之.

其实你所作的，和上面所面临的问题都是一样的。你把简单的问题都回避了，用更加复杂得多的问题取而代之。

能追求完全技术独立性的公司，恐怕全世界加起来也没有几家。ibm虽然有自己的jdk，但还是基于java规范。微软虽然有自己的操作系统，但还是基于其他公司的cpu。你所追求的，只能说是一个乌托邦式的理想。

31 楼 kjj 2009-06-02  

建议你考虑一下air或者flex吧，开发ui基本都是拖拖拉拉的模式，不用写大量复杂 的创建逻辑！！不过要定制的话，也需要自定义，但比起html来，要简单多了！！

30 楼 liujunsong 2009-06-02  

继续凑凑热闹,谈谈对ui开发的一些看法.

从根本上来说,所有的ui都包括三部分,第一部分是如何定义和实现ui的各个元素;第二部分是如何从把这些元素组合起来形成一个统一的ui,第三部分是如何把这些定义的ui元素和ui界面在计算机屏幕上绘制出来.第一部分,第二部分属于数据结构的定义部分;第三部分是真正的算法部分,把数据结构变成用户实际可见的界面.
------------------------------------------------------------------
1.HTML
假如界面上选择的是HTML的话,那么第一部分用的就是html的定义元素,textbox,button之类,第二部分采用的就是html的定义语法,把各个基本元素组合成一个页面来展示.而第三部分则交给浏览器来处理,浏览器负责将html文件转换为一个一个图形界面.
这种ui实现的缺陷很多,html的基本元素很少,而且html还不能自己扩展.只能采用第三方javascript库来扩展.
所面临的问题包括:1.浏览器升级 2.javascript和浏览器不兼容 3.js bug 4.浏览器bug.
这里最要命的就是,有时你会遇到一些bug,明知存在,却无能为力,无法修改更正,只能祈祷下一个升级版本能够解决这个问题.(真实项目中曾经亲身经历,感觉非常无力)
所有把自己的ui构建在html上的系统,都似乎是在流沙上盖房子,稳定性很糟糕.
--------------------------------------------------------------------
2.Flex
Flex是一个比较新的技术,它的语法比较奇怪,让我不由得想到VB的语法.最近因为曾经把一个VB开发的程序迁移到Flex上,更加深了我的这一感觉.Flex就是用javascript的语法,来套用VB的语言结构.关于这一问题,以后有时间开专帖讨论.现在集中来谈Flex作为应用的ui基础是否可行.
对于Flex的话,ui部分的元素就是采用Flex里面提供的各种ui控件,你也可以根据自己的需要来对这些控件进行扩展;对于界面的表示形式,则采用Adobe自己定义的mhtml文件格式来存储原始界面定义文件,然后可以编译成为中间代码,在Flash的虚拟机上运行.第三部分是通过Adobe发布的一个ActiveX控件,或者插件来完成渲染绘制工作的.
从纯粹原理的角度来分析,Flex的方案要优于Html的方案.
>从ui组件上对比,flex的界面组件比html多很多,而且可以根据需要自己定义扩展
>从界面组装方式上对比,flex的界面定义格式要比html好很多,而且还有一个官方的ide支持,容易编写修改
>从渲染算法上对比,由于采用的文件格式是falsh文件格式,采用控件,插件方式来渲染执行,比在html里面再调用其他第三方的javascript的速度,效率,安全性上都要好很多.
但这个方案和第一个方案一样,要依赖于flash控件来运行,而不是直接和操作系统交互,采用flex作为ui基础的最大风险,就来自flex工具及运行环境本身的bug和升级的兼容性.
这里最要命的就是,有时你会遇到一些bug,明知存在,却无能为力,无法修改更正,只能祈祷下一个升级版本能够解决这个问题.(Flex刚开始用,还没有太遇到,但预计以后肯定会碰到的...)

---------------------------------------------------------------------
3.Extjs等
我对javascript的研究并不深入,extjs这些东西只看过别人做的一些例子,这里也是就事论事,理论探讨一下.
这种实现方案的难度也不谈,但仍然无法脱离系统受制于人的状况,采用extjs开发ui,受限制于:
>浏览器的支持和兼容
>extjs本身的bug
>extjs和其他javascript代码的兼容
采用这种解决方案,仍然要面对同样冷酷的事实:一旦extjs有了bug,你的整个系统都将受到影响,而你却无能为力.
---------------------------------------------------------------------

4.Swing/javaFx
这个就不深入开展了,和上面所面临的问题都是一样的.它把Browser的问题回避了,把jdk的问题取而代之.

----------------------------------------------------------------------
综上所述,上面提到的四种方案,其实都存在最为要命的缺陷,那就是把自己产品的生命,完全交代给另外一方来控制,一旦这个基础结构(Jdk/Ie/Flash)变化升级,或者有了bug,应用本身将发生无法预测的情况.

现在回过头来再看SAP,它们早就看透了这一点,所以SAP公司的产品开发,是自己从头做起,绝不会依赖于外部的产品的,这些所有外部的产品,本质上是靠不住的.那些说SAP看见java出来以后后悔的人,完全是想当然.
再多说一句,所有世界性的软件公司,他们的核心技术,开发工具和开发语言,一定是自己开发一套出来用的,就算是Java语言,Ibm用的是自己的jdk,BEA用的是自己的jdk,Oracle用的也是自己的jdk,就算SAP要用java开发,它们也一定会自己搞一个jdk出来的.为啥?底层技术,是绝对不能受制于人的.

-----------------------------------------------------------------------
话说回来,上面的方案都有问题,那怎么办?怎么样才能彻底摆脱对外部产品的依赖?
我的看法是,如果要真正解决这个问题,就必须下决心一切从头开始,自己开发一套控件库,通过直接访问操作系统的方式,来完成界面的渲染工作.这样一来,才能摆脱浏览器升级的麻烦.
具体来说,就是需要做如下的工作:
1.自己定义界面的ui元素定义
2.自己定义一套界面的定义格式(由ui元素组成)
3.(核心)自己开发一个界面的渲染器,将界面定义直接渲染成图形界面,采用Activex形式嵌入到IE浏览器执行.

29 楼 logicgate 2009-06-02  

刚才查了一些netbean platform的资料（http://www.netbeans.org/kb/trails/platform.html），貌似我扩展ide提供自己的可视化ui组件和程序模板的想法是可行的。打算作一些进一步的研究。

不少朋友都建议flex和gwt，这两个都是不错的技术，而且ide支持也都不错。不过基于系统规模以及人力资源，目前很难进行这么大的重构。毕竟我现在一边讨论着这个技术问题，一边还要考虑一个印刷业成本估算的业务问题。小公司，忙啊，做点东西不容易。

只能等到将来如果换公司的话再尝试新技术了，呵呵。

28 楼 peacock 2009-06-02  

flex和extjs的性能都不是太好

27 楼 jvincent 2009-06-02  

其实GWT可以不错的解决这些UI的问题.
展现: ajax 而且跨浏览器
开发: 类似Swing的开发方式.

26 楼 logicgate 2009-06-02  

linux1689 写道

据我的不成熟了解，其实有2种途径可以解决你目前遇到的问题：
第一，用Flex极其相关技术做前端，我认识不少朋友都用Flex做企业级开发，开发效率超高，东西也很漂亮。
第二，用Ext JS或jQuery UI，或者是GWT+GWT-EXT

经过几年开发，我们现在的ui库以及taglib已经比较全了，基本上能满足系统的业务需求。推倒重做的话，这个工作量不是公司能够承受得起的，而且我觉得也没有这个必要，付出和回报不成比例。

flex是个不错的东东，如果从头让我再作一遍的话，我也许会选择flex。

Ext和jquery，可惜出现的晚了些，不然我就不用自己这么辛苦从底层写那么多js了。而且由于时间限制，我的js只兼容ie的。（哈哈，不过我们可以控制客户用什么浏览器，所以没有人抱怨）。不过基于我的研究，jquery可以解决我单纯ui显示的问题，但如果要做到快速开发和更大的重用性，我还是需要对一些jquery的控件进行进一步封装，直接的拿来主义好像不适合我们。