BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

曹晓钢谈企业应用开发框架
录制于:

| 受访者 Jason lai 关注 0 他的粉丝 作者  他的粉丝 发布于 2007年10月24日 | AICon 关注机器学习、计算机视觉、NLP、自动驾驶等20+AI热点技术和最新落地成功案例。
20:42

个人简介 曹晓钢,满江红开放技术研究组织创始人,在软件开发方面有着多年的经验积累,热衷于开源理念与开源软件的推广。此外他还有多本译作及原创书籍出版,如《深入浅出Hibernate》、《深入Java虚拟机》、《J2EE Development Without EJB中文版》等,曾是《Dr. Dobb's Journal》中文版编委会常任委员。

感谢上海卡内基信息科技有限公司提供场地支持!

   

1. 请评价目前市场上流行的企业应用开发框架。

从Web角度来说的话,如果说我拿到一个新的框架,那我会从几个方面来评价它,第一方面,它对Web端事件模型是如何封装的;第二点,他对组件是如何支持的,特别是对业务组件如何支持的。举例来说,在页面上面,我希望显示企业信息的时候,或者说客户信息的时候,那么我希望能够直接引用一个客户信息这样的组件,就能够显示出包括客户的名称、客户的简称、客户的预付款金额、客户的帐务情况,这样的一些完整的组件。可能这样的一个业务组件,并不是现在很多的Web框架所主要考虑的一个内容,但是我相信,从真实的实际的应用开发角度来说,到这个角度(程度)是不可避免的事情;第三点就是说业务框架,集成框架如何来处理数据绑定的事情,如何跟后端的ORM能够进行有效的集成,如果说我跟后端ORM是没有任何集成的,那么实际上,就变成结构化的东西,在后端必须自己做这件事情。如果是能够集中ORM集成,那么我后端的MetaData能够多大程度上简化前端的开发,这是一个要考虑的一个问题。

那么在从这几个方面,我觉得,我就能够把握住这个框架到底对我是不是有用的,到底是不是能够适应企业开发的一个应用。那么当然了,还有其他的一些特性,比如说性能问题,比如说对扩展性的一些把握,还有对可测试性的一些问题,虽然对Web的开发来说,它的性能,它的可测试性是一个非常大的问题,包括Dojo,包括qooxdoo这样的一些组件,在客户端的性能,就是相当的差,必须做很多的选择,然后再减小包的大小,你才能保证相对的性能。在这个角度上来说的话呢,我是希望,从浏览器的角度上也好,或者从框架自身的角度上也好,能够进一步提高它的性能,才能够更好地用在企业开发上。

   

2. 如果在企业应用中使用开源框架,今后的趋势又是怎样的?

那我可以介绍一下,就是说之前几年我在开发中具体使用的一些情况。刚开始的时候呢就是说,其实最开始的时候我很早,在JSP 0.8或者0.91的时候,那时候开始写Java程序。刚开始的时候呢,是一个相当无序的一个情况,直到后来出现MVC 1和MVC 2上这样的架构,慢慢逐渐(好)起来,但是实在来说,这个市场呢,比单用Delphi或者之前的CS开发呢,存在着很大的一个区别。首先一直以来没有组件这样的一个模型,导致你自己写JSP的时候,(就算有taglib,)就算你用了Webwork,就算你用了一些Spring,你仍然需要写大量的业务代码,这一点没有得到任何根本的改善。那么我觉得,从近两年开始呢,从这一点上来说,开始有了比较大的改善(迹象),比较大的一个特点呢就是像Seam这样的组件的出现,那么你要说我现在对什么感兴趣呢,就是说对Seam这样的一个组件式的开发相当的感兴趣。我们可以看到,像Spring,像那个模型,它对业务建模并没有带来很本质性的一个大帮助,(之前)我举的例子来说,就比如说,我们在写应用程序的时候,经常遇到这样的情况,我需要在界面上放一个客户的一个表示客户情况的一个Box,一个框,或者一个组件,它里面可能包含有四个字段,包括说我的客户,他的简称,他的全称,然后他的应付帐款,然后他的一个信用评价,这么一个程度,那么我在业务中认为这是一个业务的体现,那我可能在十几个不同的页面中,都同时会引用这么一个客户的一个状况的一个界面。但是假如说,当我这十个界面我都要去自己去写四个Field,或者用(类似)什么样的方式来做,那么我觉得,这是一个很不可接受的这么一个事情。

现有的这些MVC框架没有帮我解决的问题,那么我要怎么样才能解决这个问题呢,那唯一的办法就是对页面和后台的组件,我能够衔接起来,第一呢,把页面也组件化,第二,要能够处理好组件化所带来的事件和包括我界面上的数据组装,带来的这种影响。在这个意义上面来说,我从业务上考虑的事情,我要要求的就是说,第一框架本身是要足够健壮足够易用的,我要能够有很快的方式,能够组建出一个业务的雏形出来,那当然了,我不可能指望在BS架构下达到像以前CS下的Delphi或者VB这样的一个开发效率,这样的开发进度,我能够第二天就拿个模型去见我的客户说,结果就是这样这样的。(第二)我至少在里面,要能够重用我以前做的这些成果, Delphi里面,它是允许你把它自己现有的组件很快地就能组装出来,做成新的组件来使用的,或者说我可以通过页面之间的继承关系,我能够把一个Form作为一个BaseForm,然后所有的其他Form都来继承这个Form,达到一些基本的封装。那么在这一点上来说的话呢,我对现有的所有的Web框架都是很不满意的,因为它们还没有达到这么一个抽象,组合的形式,那么我觉得在所有的这些框架里面,可以说JSF是最接近这个目标的,而且Seam这样的一个组件框架是目前为止,最健壮的,最最能够反应出事物的本质的。

   

3. 那用于企业开发的这些Java开源框架之间各自存在哪些优势和劣势?

我觉得就是说像Spring这样的一个组件,主要的大家会比较拿Spring和JBoss的一套体系来做比较。首先我觉得JBoss来说,现在从标准上面或者说从商业推广的进度上来说,都是领先Spring的,一个就是说,它的确是将很多很有价值的组件整合在一起的,而且特别是,像Hibernate已经上升到JPA标准这样的一个组件,,然后呢包括像Seam这样的组件库里面也让人有新的感觉。像Spring的话,它更加有点像草根的感觉,就是能够真正的解决开发人员平时遇到的一些很大的问题,但是我的感觉是什么呢?它没有一个很大的支撑,没有一个说,让你能知道说,我过三年,我过五年之后Spring到底能不能够成为一个新的主流,我觉得在这上面的话会有所疑问。例如说,我现在用Spring,用他的整个一套体系,用IOC这么一个容器,但是呢,我用容器能带来的一个好处,我是从一个技术人程序员的角度上来说,我能看到说,我后面的Webflow能够使用它这东西。但是我对于他是不是能打通前后关节呢,能够把我用容器管理的Bean,以后我能够直接在Web上面来应用,能够跟后台的JVM或者其他的Workflow的框架能够整合起来,那么在这一点上,我觉得只能取决于Spring各个库的各个Section,它的开发的进度。

但是呢,我们现在可以看到,就是像JBoss这样的另外一种方向的话,你能看到这种保证,至少能看到他们中,那么终于有一天我可以得到像我刚才所想象的这样一个比较好的WEB业务开发的一个框架。 可以说Java的现在的Web表现层比.NET的表现层差距还是比较大的,我觉得如果我现在去开发程序的话呢,我不太愿意说,我用Java建立这么一套框架,自己搭建一套新的系统,当然我现在实际的真实的开发中间,我是这么做的,但是如果让我仔细的从各个方面,业务成本的方面,或者其他的各方面来考虑的话,假如我现在开启一个新项目,我愿用BS结构,但是我可以采用嵌入ActiveX控件的方式,或用其他方式,让我能够避免用现在所谓的HTML和JavaScript组件的RIA应用,所带来的不稳定的一些因素。

   

4. 那么像纯的这样的HTML的组件库,在企业应用开发中是怎么样的一个应用情况呢?

我觉得企业应用主要有两种情况吧,一种是使用一些比较轻量的一些组件库,比如说Prototype,或者是像jQuery这样的组件库,另外的情况呢,就是应用一些相对来说比较重型的,比如说Dojo这样的方式来做,实际上呢,第一种方式用的人会相对来说少一点,因为它看不到太多的好处,那么第二种方式的话呢,我自己以前曾经用过Qooxdoo,,但是那段时间其实带来的经历比较惨痛,因为主要的后来发现使用Qooxdoo,很多是我们使用的问题或者其他一些问题,带来比较严重的效率问题。比如一个页面,我弄的页面如果展示需要两三秒钟,我的整个应用就是不可接受的,是非常大的一个代价,最后呢,我们换到Ext上面来。其实我的第一个基本的观点就是说,你在这种两难的决择下,做得任何选择都有可能是一种赌博,你不知道你现在用Qooxdoo,或者是Ext到底能不能在两三年之后还仍然获得比较好的一个成长。为什么呢?因为所有的这些组件库之间有一些内在的不一致性,首先他们都分装了DOM里面的事件机制,但是这种分装的事件机制,都是不一样的,就面临着说,你选择的这种事件机制,你可能在一两年之后,发现说由于整个组件库发展不尽如人意,你想切换到另外一种组件库的时候呢,你根本上很难切换过去,你就被粘住了。

本质上来说,这是因为现在HTML的分裂的现状造成的,所以说浏览器大战中间,我到现在为止,FireFox和IE之间的DOM的事件模型,都还存在不一样的地方,产生了很多的封装,本身这种封装就是不规范的,那么我们现在在诸多的不规范的封装里面选择一种来使用,就是很冒风险的事情;第二个就是说,你把这种框架跟后台的你的整个的一个Java的一套体系结合起来的过程中间也会遇到很多的问题,因为所有的这些框架在前端的话,它们对数据绑定都是没有特别多的考虑,但是我们再到后台的时候,我是希望我能够把我EJB3或者说Hibernate里面所产生的ORM的对象图,整个的一套面向对象的一套定义,我能够直接穿透到前方去,能够在我的JSP里面或者说在我的前端的Web浏览器环境里面能够直接使用。

举个例子来说,NOT NULL这种属性,我在业务上面来说,我这个业务,我需要在我的一个标志上面打上一个黄色的星号,提示客户说,这是个必须输入的属性,并且如果他不输入的话呢,我要进行一些校验,告诉他出错了,那这种情况,我不希望我在前面我再重新定义一次,我不希望就是说像类似的这种东西,我都要重新来做。这是个很烦琐的事情,我当然希望我在服务器端,在我的操作界面,在我的pojo里面,我用一个annotation,把这些定义完之后,所有的一切事情都是自动化完成的。那么放大来说,前面我说的业务组件也是一样的,业务组件,我在后台一定是用一个语义模型来把它调试出来的,那么我怎么样在前台的界面里边展现这个模型?我可以用不同的View,但是我希望我定义完View之后,我前面的整体就能够组合起来。那么这件事情,所有的现在前台框架都没有替我做这件事情,所有后台的这些组件库也没有替我做这件事情,那么这个事情是我自己来做的,那么我觉得就是说在企业领域里面,这是以后所有的这些框架所面临的一个主要问题,需要解决的一个问题,但是呢,我不确定,它们是不是以后能替我们解决,所以可能我们还不得不继续做这种工作。

   

5. 那你觉得就是在企业开发中这个业务组件的重用,今后会不会是一个比较大的一个方向呢?

不光是今后,包括这么多年来,大家写程序的时候,实际上,一直是在做这种重用的工作,比如说,刚开始的时候,大家用JSP的Tag来做这种工作,我以前自己也做过这种工作,当然后来很多时候被证明,这是一个事倍功半的工作。但是不得不承认,最简单的JSP include,虽然能够带来一些便利,但是有可能让你的代码变的很难解读,很难懂,但是我觉得如果组件,业务组件本身能替你完成这些事情,这是一个很漂亮的工作,我当然很期待这种事情。

   

6. 刚才你就提到这个用组件化来实施项目的这样的一个思想,那么就是说在你现在具体实际项目实施当中,你是怎么去实现这样的一个思想的呢?

是这样的,简要介绍一下我们现在具体的一个做法,我们在前端的话呢,是用Ext,然后后端的话呢,是用Spring做容器,然后用Hibernate来做一个数据存储的一个解决方案,那么在这个过程中间,我用Buffalo,就是陈金洲同学写的Buffalo来做中间的数据转换的一个过程。然后在前端,我们是模仿Delphi,把页面上所有内容,我分类成一个描述办法,然后再把它渲染出来,在客户终端中间就需要用一些Data Source为某个页面提供数据;例如来说,一个典型的CRUD界面,可能是由一个List页面和一个Detail来组成的,Detail呢,可能相对来说比较复杂,比较复杂在于什么呢?它可能自己内部包含一些Grid来表述一些它的一些属性,简要的来说,我们可以举一个例子吧,比如说我们维护一个客户,客户可能他还有他自己的上家,他还有下家,那么在这样的一个页面中间的话呢,我们可以牵扯到三个不同的对象,就是说首先是客户本身,那可能还有客户的上家对象,客户的下家对象,那么在这个页面(开始),可能是一个List页面,点击List页面之后的话,(界面转变)变成一个Detail,Detail页面上方显示客户他的一些详细的一些情况。那么在下面是Grid,两个Grid,分别显示他的上家的一些内容,和他的下家的一些内容。那么具体在Detail的界面里面呢,有可能需要三个Data Source,一个Data Source是客户本身自己的一些数据来源,那么还有他的上家,他的下家,这是两个独立的Data Source,关联到后方去。

实际上,我们知道在服务器里面,我们定义的Hibernate是一个对象图的一个关系,那么客户对象他用一对多,关联到他的一个上家,再用一对多关联到他的一个下家。那么在前端,我们定义完整个的后端对象图之后的话呢,我们在前端不应该在定义上面的这么一个对应的关系,我只需要表明说,我一对多关系在前端我需要用Grid来体现出来,然后我在定义我这个Grid里面,我使用的这个一对多的关联他的这个对象的他哪几个字段,分别去怎么样显示的,那么OK,页面自动的就会知道,我把Grid定义出来,并且Grid里面每一个字段,它应该是什么类型,添加的时候呢,可能有些是预期类型。首先它是一个Lookup的类型,甚至它在Lookup另外的一些体现。那么在这样的一个情况下,我们就认为说,我们可以把它的业务定义,把它的Domain的一些Metadata一些属性就可以穿透到前端来,减少前端编写的时间。

当然了,具体的一些业务的问题仍然是需要在服务器上做的,我们不鼓励业务逻辑放在前端来解决,还是放在服务器端来做业务的一些处理的,在整个过程中间比较复杂的一些就是说,第一我对组件的一个抽象化的处理,那目前我们在客户端呢,把整个组件分成了两种,一种是容器类的,另外一种就是字段本身的一个就是业务表示,你例如说,我们认为Grid和Field Set,这是两种最基本的容器,然后在容器里面的话呢,我会用不同的形式来表达我的业务的一个字段,可能这个业务字段是一个lookup的一个table,或者是abstraction的一个box,甚至可能是我们今天做的是用拼音来做的combobox,输入前两个字母之后,我就把符合声母的客户名称列出来,那么也有可能是一个Grid,但是Grid里面的话呢,我需要另外一个定义,那么比较复杂的一个问题呢,就是一个事件的处理,那么在整个的一个模型中间,对事件已经是做一个包装的,我们目前呢是基本上直接使用Ext的事件,那么事件,特别是在需要跟服务器端交互的时候,如何映射到服务器端,那么这点我们觉得我们做的还不是特别好,那么在这一点上面,JSF它是有一个比较好的解决方案,特别是说Ajax for JSF这样的一个解决方式,它是利用一些Tag,然后在Tag上面直接指定说,我能够访问到后端的JSF具体的一个事件,这点上面呢,我觉得我们也可以向Seam构架学习,这点上,这是我们以后努力的一个主要的方向。

   

7. 假如今后你有无限的时间和精力的话,你要解决这样的一个项目中出现的问题,你会怎么样去选择呢?

实际上企业开发很多时候都是一个Trade off,就是个妥协的过程,我们在运作的过程中,开始的时候,也设想了很多先进的一些方式来解决问题,但是最终呢,由于时间的问题没有想出很多办法来实现,那假设说我要想列出一些主要想解决的问题,第一个呢就是说,我要给我的form编辑器写一个比较好的一个实用的一个小的编辑方案,能够让form编辑变的简易一些,如果说能够达到像很快的给客户做一个演示出来,那我觉得对整个项目是有很大的帮助。目前为止的话呢,我们在服务器端用编码的方式,是用类似于我们自己做的一套类库来做定义的工作,但是呢可能是需要用更加好的机制,比如说Ruby DSL定义成form,来定义之间的这种交互性的操作。然后这样是一个比较好的一个方式,第二个呢,就是说更综合了,有一个更好的结合,在这一点上的话呢,我觉得像现在Seam的一些处理方法是值得我们借鉴的,比如Seam它是把Pojo跟后端的JBPM,能够完整的连接在一起,这样的话就能够很好的利用服务器端的工作流的基础设施,那我们现在因为没有太深入,所以我们自己呢,就是做了一些小的一些改良,是比较微不足道的,很难具有说服力,这点上面的话,我们是希望的能够有所改善,能够跟后端结合的更加紧密。

那么还有一个就是,主要的一个比较大的问题就是效率的问题,就是客户端的效率的话呢,因为由于时间的关系或者其他原因,我们没有办法做更多的这种效率优化的工作,如果能够有这么多时间的话,你客户端,就是Ext如何在具体界面里面使用的时候做更多的选择,然后呢,做更多的局部优化,能够满足效率的提升。你比如说我刚才说到的,我说我用Ajax从服务器端调出一些数据来,但很多时候呢,事情是可以优化的,你比如说我第一次装载页面的时候,我完全可以说,我把数据我就直接跟Ext页面一起传递到前端,节省掉一些解释的时间,你甚至于可以说,我把能够把缓存的JavaScript,我尽量能够缓存到客户端,甚至于使用NETBox这样的一些其他工具,我把整个JavaScript我都处理了,做一个小的客户端界面出来,这种事情都能够明显的改善客户端的用户体验。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT