基于J2EE架构的企业应用开发新思维.doc

基于J2EE架构的企业应用开发新思维1前言22 Web开发的困境32.1概述32.2Web系统开发的复杂性32.3开发人员的困境52.4维护人员的困境62.5科技公司（乙方）的困境72.6客户(甲方)的困境82.7原因分析103 Web应用以谁为中心？浏览器？服务器？113.1B/S的历史发展沿革123.2计算模式历史143.3初步结论143.4新模式技术架构143.5新模式技术范围163.6新模式下人员分工174 J2EE框架批判184.1关于J2EE开发的比喻184.2从C/S开发模式反思分层的必要性194.3技术框架上的皮之不存,毛将焉附204.4 J2EE系统架构的致命缺陷214.5 Hibernate是垃圾224.6为什么J2EE如此低效-用户无法参与开发234.7谈谈对web开发UI基础架构的一些看法275 Web企业开发困境原因分析315.1分工过细315.2技术路线多头并进325.3开发维护复杂度太高335.4客户无法参与336解决之道346.1 WebDW产品说明346.1.1 WebDW简介346.1.2 WebDW设计思路3 WebDW释义3 WebDW的设计理念3数据窗口对象说明376.1.3 界面示意图（同一个界面文件，VB，Java，Flex版本不同实现）386.2其它可行的技术方向396.2.1跨越语言和平台的鸿沟397结束语401前言在企业级的应用系统开发领域，J2EE架构现在已经被普遍接受了。虽然它并未完全兑现刚刚出现时的种种美好许诺，跨平台，分布式，易于开发维护等等，但J2EE的广泛普及，已经是一个不争的事实。虽然J2EE已经非常普及，但从技术上来讲，它本身还是存在很多缺陷的，比较突出的缺点，就是开发效率低，维护更加复杂，许多项目组都陷入其中不可自拔。本文将就造成这一现象的原因进行初步探讨，并在此基础上提出自己的解决思路。本文讨论的范围仅限于采用B/S开发企业的应用系统，不涉及网站类型的应用开发。讨论的技术方向，主要针对J2EE，其余技术方向不作为重点讨论，仅供参考。本文先从Web开发的现状困境开始，分析造成目前困境的原因，然后通过回顾B/S技术架构的演化，以及对比C/S和B/S的开发模式的差异，提出一套新的开发解决思路，最后介绍WebDW系列产品的设计目的和简单功能，再以此为基础来进行扩展讨论。2 Web开发的困境2.1概述说明：Web应用系统的开发，像一座大山一样，把所有的人都压垮了。自互联网出现以来，企业应用系统的架构发生了很大的变化，C/S架构被废弃，B/S成为绝对的主流。但B/S架构本身，要比C/S复杂的多，加上新技术层出不穷，整个行业都处于巨大的困境之中。Web应用系统的开发，就像一座大山一样，把所有的人，无论是甲方还是乙方，无论是开发人员，维护人员还是系统用户，都被累垮了。2.2Web系统开发的复杂性B/S系统本身的架构设计，要比C/S系统复杂很多，在C/S架构中，一般是两层结构。如下图。一般在这种架构中，服务器是一个数据库服务器，只负责数据的存储和读取访问支持；前台程序采用 VB，PB，Delphi 等图形开发工具来开发，通过网络直接连接到后台的数据库服务器，通过发送SQL 命令来实现数据库的访问。这种开发环境下可以使用图形化的控件来搭建用户界面，用户的交互性比较好。缺点在于应用程序发布在客户端，如果客户机数量很多的话，客户机程序的安装，升级都比较困难。而在B/S结构中，涉及到了多种服务器类型，Web服务器，App服务器，DB服务器。如下图。在B/S系统中，用户通过客户机上的浏览器来访问后台的Web服务器，Web服务器再把相应的请求转发给应用服务器来处理，应用服务器再将其中的数据访问请求转发给数据库服务器进行处理。在C/S系统中，应用系统或者应用程序本身是一个完整的，独立的整体，一般采用一种开发语言来开发即可，这种开发语言不仅负责用户界面，也负责业务逻辑控制，以及数据访问请求的生成发送，主要的开发和执行工作是在客户机上完成的。而在B/S系统中，整个系统的架构要复杂的多。首先，客户机上只有一个通用的浏览器，用户操作界面是通过Web服务器返回的HTML语言来进行描述的，如果需要一些动态特征，则不得不通过在HTML页面中嵌入JavaScript来实现。在应用系统中，大量的页面是动态，而非静态页面，因此必须在应用服务器上完成动态页面到静态HTML的转换工作。如果动态页面中包含数据访问请求，则又必须访问后台的数据库服务器来协助完成此项工作。以J2EE标准流程为例，当用户在浏览器上输入一个地址，或者URL以后，这个URL首先传递给Web服务器，然后再转发给App服务器来解释执行。假如请求是一个jsp页面，应用服务器首先读取这个文件，然后把它翻译成一个java文件，再编译成一个class文件，再解释执行这个class文件，如果需要再访问后台数据库，最后产生一个HTML格式的输出文件流，返回给Web服务器，再返回给客户机浏览器解释成一个界面。与C/S开发的一种语言包打天下不同，B/S系统的开发需要在多个层次上进行编程开发：浏览器中，用HTML和JavaScript编程；应用服务器上，用Java或者.net之类编程，数据库服务器上用SQL语句编程。在C/S开发中，最终的产品是一个Exe文件；而B/S开发中，最终的产品是一个网站，里面包含成千上万个文件，而且是各种不同类型的文件：HTML,图片，JSP, Java, Class, XML等等。在Web开发中，人们为了简化开发过程，提高效率，陆续发明了很多新技术，在页面开发上，基于JavaScript本身，发明了如prototype, jQuery, Ajax等框架；基于java技术，发明了J2EE架构，基于J2EE架构，又发明了Struts, WebWork, Spring, Hibernate ,Itabtis等无数的框架产品。结果在试图解决问题的同时，这些产品本身又造成了新的问题。相对于C/S开发的单一开发工具开发，B/S开发要涉及到很多工具，语言和框架，这些工具，语言和框架，都是为了解决某一问题而设计的，而开发人员必须把这些目的不同的东西整合起来，才能搭建出一个整体的系统。B/S的复杂度，很大程度上是由于涉及的技术面太多，太多的产品，太多的技术，太多的框架，这样不仅增加了学习的难度，增加了学习技术的成本，而且也增加了系统运行维护的成本，最终提高了整个系统的开发，运营成本。这种高昂的成本让开发人员，维护人员，开发公司，和甲方都陷入了困境之中，大家在这一困境中挣扎，不能自拔。2.3开发人员的困境在B/S系统的开发中，开发人员是最辛苦的一类人。用户的所有需求，都需要一行一行编写代码来实现，项目时间紧，加班加点干，最苦恼的是，要完成一个基本的功能，需要学习一大堆东西才能实现。HTML, JavaScript, Ajax, Jsp, Servlet, EJB, Jdbc, Struts,Spring ,Hibernate,光是技术名词，恐怕一张纸都列不完。开发人员面临的困境，就是技术本身在快速演化发展，不时有新名词，新概念出现，同时现有的技术也在快速演化之中，真是生也有涯，而知也无涯，感觉象夸父追日一样，每日不停的奔跑追赶，何日才是尽头啊。另外一个头疼的事情，就是技术架构的变化性，今天一个语言，明天一个语言，一旦底层的平台变了，自己费劲力气学会的东西就一文不值了，年龄一天一天大了，那里有那么多的精力老追赶新技术呢，于是很多人转行离开了。但仔细想一想，所有这些架构，这些技术，真的那么必要吗？为什么一定要忙于学习新的技术，而不是把精力用在用好现有的技术上呢？为什么一定要受限于某种具体的语言和技术，而不是采用跨语言的解决方案呢？为什么一出现新的技术，就把原来的代码全部推翻重写呢？为什么要用这么复杂的架构来实现原来一种语言就能实现的简单功能呢？譬如，以非常流行的Hibernate来举例说明，Hibernate的设计目的，是简化ORM过程，使得数据库的数据表可以容易的映射成一个Java对象。但问题是，为什么一定要把数据表映射成一个Java对象呢？如果这种映射本身就不是必须的，那么Hibernate试图解决的问题，原本就是一个不存在的问题，那么这个产品的价值又何在呢？以我的观点，Java世界里面这么多框架，产品，语言，很多都是这样的思路，不是在试图解决问题，而是在不断的创造新的问题出来。开发中用的产品，技术越多，系统就越复杂，光是学习这些技术，框架怎么使用，就把开发人员的时间和精力耗去大半，而究竟应该怎样来设计实现系统，已经没有人考虑了。时间和精力被无谓的消耗掉了。这才是开发人员最大的悲哀所在。Web开发压垮的第一批人，是开发人员。压垮他们的，是系统的复杂性。2.4维护人员的困境终于，在多次延期，多次修改，无数次补丁以后，系统终于上线了。现在轮到维护人员来面对这个庞然大物的系统了。系统维护人员，对自己的工作，有一个形象的，不太雅观的比喻：擦屁股。系统本身开发起来就复杂，使用起来也复杂，再加上开发过程中隐藏的错误，行业术语叫Bug，维护人员的电话一直没有停过，除了操作指导，就是错误报告，再加上误操作以后直接在后台数据库里面改数据，反正事情又多又杂，整天忙得不亦乐乎。如果是开发人员自己来做维护，相对还好一点，至少里面是怎么回事情，大概知道个差不多，有了问题，小修小补打打补丁，虽然累点，总还是有希望的；如果不是自己开发的，要来做维护，那就要了老命了，要文档没文档，要注释没注释，还要面对同样多的技术架构，语言和技术平台，用维护人员的话说，就是如履薄冰，如临深渊，每天都在祈祷，这个系统别出问题。从表面上看，是开发人员和维护人员之间的矛盾；从本质上看，是系统复杂度的矛盾。如果一个系统开发的很复杂，那么它本身就很难维护，即使勉强维护，维护的成本也很高。如果你在系统里面用了10项技术，那么维护人员就必须学习10项技术才能进行维护；如果你在系统了写了10万行代码，那么维护人员就必须面对10万行代码。当维护人员觉得系统已经无法支持下去时，他们会一走了之。而新来的人对于这个系统，工作的难度只有更高，更加难以胜任。当一个系统无法维持正常的维护时，它的寿命也就到了。这时就会把它推掉，重新开始一个新的系统开发。不幸的是，新的系统一般来说会重复旧系统已经走过的路线，开发的更加复杂，更加难以维护，最后再次陷入无法维护的境界。为什么系统变得难以维护，因为系统太复杂；为什么维护人员无能为力，因为系统太复杂；为什么维护成本居高不下，因为系统太复杂；Web系统压垮的第二批人，是系统的维护人员，压垮他们的，还是系统的复杂性。2.5科技公司（乙方）的困境和对个人的收益不同，系统复杂性，带给科技公司的，既有收益，也有风险。系统复杂度的收益，就是客观上的跑马圈地，一件事情简单了，能做的人就多，竞争就激烈，最后就不好赚钱。CPU不是谁都能设计的，所以Intel发了；OS不是谁都能开发的，所以MS发了。把Web系统搞得很复杂，就会人为提高它的门槛，能做的公司少了，竞争就会少很多。早期的C/S阶段，把整个MIS系统搞得很简单，开发门槛太低，于是有一大堆的公司来做，最后大家都难以生存下去，现在的外包公司，也不需要公司有啥技术积累，于是有一大堆公司一起做，最后大家都挣不了钱。从这一方面来说，系统搞的复杂一些，对科技公司来说，客观上是有一定好处的。最大的好处，是提供这种复杂性的基础设备的公司，例如Oracle, BEA, SUN, HP这些。以Oracle为例，每升级一个版本，就可以访问更快，存储更多，也就能卖更多钱。但问题是：究竟有什么必要在系统中存储那么多的信息呢？这些信息真的增长那么快吗？还是垃圾增长快呢？基于这个原因，所有的基础设备提供商，都在不遗余力地推进系统的复杂性，今天一个标准，明天一个标准，如果有现成的标准，就把这个标准不断升级，让你跟着跑，整天疲于奔命，永远处在追赶之中。最典型的例子就是Microsoft了，无论操作系统也好，Office也好，IE也好，反正三年必升级，强制性让你报废现在的东西。这就是基础设备提供商的生命所在，不断增加系统的复杂性。对于具体的开发公司来说，系统的复杂性就是可怕的敌人了。系统越复杂，开发的成本就越高，维护成本也越高，如果客户不为这些来买单的话，开发公司就会做一个项目，赔一个项目，最后把公司赔光，关门拉倒。在人月神话中，讲述了恐龙在泥沼中挣扎，挣扎的越厉害，险的越深；现在很多的开发公司也是一样，险在项目之中不能自拔，活儿越干越多，不知何日才是头，最后一算账，还不能挣钱。对于公司来讲，人力成本居高不下，所有人员被困在一个个项目中挣扎，公司永远长不大，变不强。很多人会讲这个现象归咎于大环境和客户的不成熟。也许他们是对的。但从深层次看，还是系统的复杂度问题，系统太复杂，以至于把开发公司的人力，物力，财力都消耗殆尽，根本无力发展。在一个复杂度无法控制的状态下，公司只能是疲于奔命，随波逐流。Web系统压垮的第三批人，是一个个开发公司，压垮他们的，还是系统的复杂性。2.6客户(甲方)的困境Web系统的复杂性，依次打垮了开发人员，维护人员和开发公司，现在轮到甲方来承担它的后果了。甲方的科技人员对于系统的复杂性，往往缺乏先见之明。所有的招标文件中，一律指出要保证技术的先进性，素不知，所谓的先进性，往往也意味着新技术，对于整个系统而言，往往是增加其复杂性，而不是减少其复杂性。国内的甲方对于项目开发往往有个误区，喜欢按照人员的工作量，通常是人月来估算项目的费用，预算和成本。其实这是很不取的。很多时候只是盲目的要求增加人手，却不考虑到底有没有这么多工作需要人来做，或者做这件事情的时机是否成熟，是否合适。在按人头计算费用的模式下，开发公司倾向于增加人手来提高整个项目的费用计算，而且最好是增加低成本的新手来做项目，这样做的结果就是整个项目陷入盲目运行的状态，所有的人都在忙，但不知道在忙啥，整体作的是无用功。很多时候把甲方的人员也拉了进来，包括业务人员和科技人员，大家一起瞎忙，一起浪费时间做无用功。项目开发的种种问题，最后的恶劣后果，实际上都是由甲方来承担的。甲方既是项目的投资人，也是最终的使用者，如果项目不能达到目标，最终买单的是甲方。项目的过程管理，时间管理这些都先不谈，单独谈谈项目的复杂性对甲方的长远影响。首先是开发成本的失控，项目越复杂，开发的成本也越高，这些不必要的成本，或者说资源的浪费，最终是由甲方来买单的，开发公司最多不干了退出，甲方却退无可退，硬着头皮也要把项目做完。其次是项目最终难以维护，正如上面所谈到的，系统越复杂，以后的维护就越困难。而更加要命的是，一个企业内部会有多个系统，这些系统分别由不同的开发商在不同时间按照不同的技术来开发，有的甚至已经换手几次。而甲方的科技部门要同时维护这样并行的多个系统，再考虑各个系统之间的交互关系，最后的结果就是焦头烂额，忙得不可开交。从整体上来看，甲方对于信息技术可以说是又爱又恨，一方面，现在的企业运行离不开这些系统，另一方面，这些系统在带来便利的同时，又带来了无穷无尽的麻烦。每个系统的搭建费时费力，最后用不了几年就漏洞百出，不得不推倒重来。整个系统的建设在不断重复这一故事，直到下一个轮回开始。有的甲方是家大业大，浪费点没啥，他们可能不太在乎系统建设时浪费的一点点资金，但对于系统运行带来的烦恼也是无可奈何。而有的甲方本身的底子就比较薄一些，这些系统建设上的浪费和失败就可能直接导致企业的巨大损失。行内有句名言，不上ERP是等死，上ERP是找死。说的就是这种现象。顺便说一下前几年的ERP热，以后随后对ERP的全面质疑。尽管角度不同，论述的结论也更不相同，我对这方面没有研究，不好妄论。但无论那种观点，都承认ERP是一个非常复杂的系统，而无论开发，实施，维护一个复杂的系统，其成本都是非常高昂的，无论那个环节跟不上，都会带来项目的失败和停滞。项目的复杂性，如果没有能够压垮甲方的话，甲方就会继续和项目的复杂性进行持续斗争。如果压力过大的话，甲方就会发现，自己本来是一个业务性的公司，最后却不明不白变成了一个IT相关的公司，信息部门最后变成了尾大不掉的一个部门。甲方的困境，简单来说在于成本的投入和收益不成比例，由于系统的复杂性不断增加，甲方的投资被不断消耗在调合系统的复杂性上，而不能用在更有效益的地方。现在的项目开发现状，使得很多甲方变成了一朝被蛇咬，十年怕井绳，对于后续项目的开发，早已失去了往日的激情和动力。根本的矛盾，仍然在复杂度上，只有降低项目的复杂度，才是解决问题的根本途径。2.7原因分析虽然在人月神话中，布鲁克斯已经指出：软件的复杂性是它的本质特性之一，但在实际工作中，人们往往容易忘记这一点。软件的复杂性来源很多，但B/S系统的复杂性，又对C/S时代更有进步，尤其是J2EE的项目开发，其复杂性在不断增加。具体原因很多，但涉及的技术太多，是重要原因。目前，B/S系统开发涉及的技术面太多，在界面展示，业务流程，数据操作等多方面，目前一般采用不同的技术方案，不同的框架，不同的产品来处理和实现。这些产品本身都是相对独立的，都构成一个自己的知识体系，而要把这些不同范畴的技术整合起来，使之成为一个统一的整体，光在技术层次上，就构成了一个非常复杂的系统。 以我自己亲身经历的一个项目为例，在这个项目中，数据库用的是Oracle，应用服务器用的是Websphere，非机构化存储用的是FileNet，数据加载用的是BO的Data Integration，报表工具用的是Congo，身份认证用的是Troliv 和 Microsoft的Active Directory，还有自己编制的邮件监控服务，林林总总，一个项目用了不下7种产品，其中任何一个产品都需要依赖专业知识才能正常使用，更别提把这些产品混合起来搭建成一个系统了。一个系统涉及的内容越多，也就意味着出现错误的几率越大，这样一个系统也就更加不稳定。而系统的价值，就在于它的稳定性，一个没有起码稳定性的系统，是不会产生价值的。在传统的J2EE框架内，应用开发已经太过复杂，变得臃肿庞大，这一点业内已有定论。正是基于这个考虑，近年来出现了一些试图简化这一过程的产品和框架，例如Spring, Hibernate，都是这种思路的产物。但不幸的是，诸如Spring, Hibernate这样的产品，在解决某一问题的同时，又往往带来更多的问题，只是用一个问题代替了另一个问题，从整个系统的角度来看，整体的复杂度不仅没有减少，反而有逐步增加的势头。开发人员现在需要学习的东西，不是更少了，而是更多了；工作不仅变得轻松，反而更加复杂，更加混乱，也更加没有生产力了。3 Web应用以谁为中心？浏览器？服务器？企业Web应用，指的是企业内部使用B/S架构搭建的企业信息系统，用户一般局限在企业内部，为了适应企业某个业务流程而设计开发使用的系统。出于跨地域部署升级的考虑，一般采用B/S模式进行开发，避免在每个客户端安装配置的麻烦。一般情况下，前台浏览器特指IE浏览器，前台操作系统选择Windows操作系统。非Windows操作系统的客户机与非IE的浏览器不在本文讨论范围之内。本文主要讨论以J2ee架构为基础的Web应用，其他架构的暂不讨论。IE浏览器WebApp服务器DB服务器在这种情况下，数据存储在数据库上，一般没有多大疑问。而附件文件一般存放在Web服务器上，也没有太大疑问。最主要的问题是：整个应用应该是以浏览器为中心，还是以服务器为中心？在J2ee出现的早期，这一问题是不存在的，当时的浏览器，基本上可以看成是互联网时代的终端机。当时的计算模式，是完全基于后台服务器的计算。3.1B/S的历史发展沿革计算时代划分浏览器服务器总结史前时代/静态页面的时代仅支持Html，只能显示文本和图片静态文件存储；静态时代，没有动态内容史前时代/CGI动态页面时代仅支持Html利用CGI方式动态生成一个HTML文件给浏览器动态时代，动态信息由后台服务器计算产生，与前台无关Java AppletActiveX控件时代浏览器里面可以嵌入其他应用程序来显示动态内容JavaScript出现浏览器第一次拥有了计算能力，把计算资源从服务器上解放了出来J2EE时代应用服务器时代Applet被废弃Javascript开始发展后台采用J2EE架构，JSP等多种方式生成动态页面J2EE架构把系统的重心牢牢地绑定在后台的应用服务器上后J2EE时代开源运动时代Javascript开始大发展，Ajax出现J2EE开始走向没落，为弥补其缺陷，开源框架出现。SSH大行其道应用服务器不堪重负，轻量级别的框架开始出现作为替代品。客户端王者归来Ajax时代Ajax风靡一时Javascript框架大量出现。Flex/SL/ExtJs各行其道服务器端处于停滞状态，JSF昙花一现后台的问题已经基本解决，现在关注的重点又转向前台，解决用户界面和友好性问题。未来自定义浏览器时代浏览器中的浏览器Flex大发展SL大发展自定义ActiveX 大发展JavaScript逐渐衰退服务器进一步弱化，弱化为为前台提供必要服务，应用中心转移通过Ajax技术,利用DWR等工具。浏览器终于把握了应用的全面主动权。从整体上来看，整个应用架构的发展，体现了从理想的B/S架构到C/S架构的回归过程。3.2计算模式历史字符终端/哑终端/主机 时代Unix图形化终端/客户机/服务器 时代Apple, DOS,Windows,Oracle哑浏览器时代Netscape/ ApacheApplet时代AppletJ2EE时代WebLogic/Websphere/JBoss后J2EE时代/开源框架时代Struts/Spring/HibernateIBMApple / MSOracle/SybaseNetScapeSun / JavaBEA/ApacheIBMRIA时代Flex / SlightLight / ExtJSAdobe / MSJavaScript3.3初步结论核心问题在与浏览器和服务器的合理分工。把所有问题压在浏览器或者都压在服务器并不合适。3.4新模式技术架构按照上面的演化过程，可以提出一种全新的，以浏览器为中心的技术架构模式。序号通用功能浏览器功能服务器功能备注1用户界面渲染渲染Html为标准用户界面；可能内嵌一个自定义的界面渲染工具；以纯静态HTML页面为主少数以JSP形式提供，动态生成以浏览器为主，服务器为辅助功能。访问采用标准HTTP协议进行2动态数据访问(数据库读取/存储)调用后台功能接口，得到标准格式的数据包信息；并对这些数据进行渲染提供标准访问接口，供浏览器进行调用前台发送调用要求，后台响应返回结果。调用方式可采用DWR模式进行3界面跳转浏览器根据本身状态变化主动跳转存储页面跳转规则，将此规则以标准方式发送给浏览器4SQL生成可以在浏览器生成可以在服务器生成两面都可生成，后台生成SQL，前台可以看到5业务逻辑可以在浏览器实现可以在服务器实现如果在后台实现，前台通过Ajax或者DWR方式调用6开发语言工具JavaScriptExtJsActiveX控件COM调用Pure Java开发SSH等开源框架EasyCare开发平台根据需要选择7核心问题数据交换规范数据交换规范数据交换的标准化是系统框架的核心问题数据库服务器/ 数据信息表应用服务器 / 应用标准服务提供层标准服务：服务1，服务2，服务3，服务4，服务5业务管理服务: 服务1，服务2，服务3功能1功能2功能3功能4应用系统服务提供规范说明定义3.5新模式技术范围序号运行点所使用技术说明1数据库服务器SQLOracle标准SQL语句在服务器端编程开发，创建，维护数据表2应用服务器JavaServletJSP采用标准Java语言，在应用服务器上编写Servlet，对外提供标准服务3浏览器HTMLCSS标准的HTML,CSS样式来实现渲染，此功能要弱化4浏览器JavaScriptExtJSJavaScript调用Extjs等来实现数据处理，动态界面内容的渲染5浏览器ActiveXFlex采用插件形式来实现对界面动态数据的界面渲染6浏览器JavaScriptAjaxDWR通过DWR等Ajax技术实现前后台的功能调用，后台提供数据，前台负责对返回数据的动态界面渲染3.6新模式下人员分工序号角色技术特长说明技术难度1项目经理负责项目进度管理中级2架构师ALL确定系统技术架构，明确那些技术可用于此项目，如何使用此技术中级3DBA数据库管理数据库规范设计，编写数据字典中级4后台服务开发JavaServletJSP利用Java语言，编写后台的通用服务功能，编写前后台的标准数据访问规范高级5前台界面开发人员JavaScriptDWR利用JavaScript,调用后台提供服务，编写前台的显示界面，主要语言为JavaScript，可能嵌入其他ActiveX控件，JS控件初级6前台控件开发人员JavaScriptExtJSActiveXVB,VC利用JavaScript, VB, VC等工具，编写前台通用的页面级别的控件。这一控件专注于对数据显示的界面渲染以及对数据的处理过程，但此过程不涉及与后台的数据信息交互。高级7项目秘书Word编写各种文档，将原始文档归档，格式化。初级4 J2EE框架批判这一章节主要是将以前零星编写的关于J2EE框架的一些感想集中起来，文字方面没有进行太多的润色。主题思想是对流行一时的J2EE框架进行批判。对J2EE框架进行批判的目的，并不是要否认其本身的技术价值，而是指出单纯采用标准的J2EE架构开发，将会面临那些问题。4.1关于J2EE开发的比喻打个比方. 现在的j2ee开发,就好象对面来了一个人. 最外面穿着一件风衣(HTML) 风衣里面穿着西装(Struts) 西装里面穿着马甲(Spring) 马甲里面穿着衬衫(Hibernate) 衬衫的里面才是真实的人(数据库) 全部衣服都是采用棉布做成的(Java) 每件衣服上都可能有其他配件(第3方库) 各件衣服之间需要配套使用(版本兼容) 如果你想看到这个人到底长啥样,必须得:先脱一件,再脱一件,再脱一件.最后才能看到最终数据库里面的数据是啥样子. 在很久很久以前,这个人是不穿衣服的. 你直接可以看到他(SQL语句) 现在不行了,你必须穿越层层衣服来看这个人. 每件衣服都是不同的厂家做出来的.而且随时在改变. （patch包）你必须自己把这些衣服一件一件套上去,祈祷他们大概能够合身.(版本兼容)4.2从C/S开发模式反思分层的必要性在今天的Java Web开发中,各种模式,框架层出不穷,颇有长江后浪推前浪,前浪死在沙滩上之势.但这些框架,真的是那么必要的吗? 回顾十年前,当时只要学会一个开发工具,VB也好,Delphi也好,PB也好,VC也罢,在一个开发环境里面,所有的应用开发就全部解决了,当时有这些框架吗?没有.当时的系统比现在功能简单吗?不简单.当时的开发效率低吗,不低.由此看来,现在这么风光无限的种种框架,也许根本没有必要存在的必要. 究竟是什么原因,使得人们放弃了已经成熟的开发方式,转向现在这种漏洞百出的开发模式,动不动一个框架,动不动一个架构的处境呢? 原因很多,厂家的推波助澜,客户的随波逐流,大家一起跟风的结果. 我这里不打算分析那么多原因所在,只是谈一谈我对B/S和C/S开发的一个看法. 在C/S程序的开发中,界面,应用,数据这三者是统一在一起的,当你思考一个问题的时候,这三者是统一的一个整体.最典型的设计方案,就是所谓的IPO图型. 某个业务流程,它的输入是什么,从那张表来,这是I,Input. 它的输出是什么,到那张表去,这是O,Output 在这个业务过程中具体做那些处理,这是P,Process. 业务分析也好,数据处理也好,都是具体围绕这个IPO来进行的,在此基础上再进行数据表结构的设计,算法的具体设计,再加上用户界面,程序就开发完成了. 这样的一个程序,它的逻辑,界面,数据三者是统一在一起的,理解它的时候,也是统一在一起理解的. 不幸的是,在B/S目前的开发过程中,出于进化的原因,上述的模式被颠覆,被否认了.这里的讨论主要是针对Java的业务系统开发,不涉及其他开发模式. 就拿现在流行一时的SSH模式来说吧. Struct作为Web层的框架,Spring作为应用层的框架,Hibernate作为数据持久层的框架. 如果仅从Java开发的角度来看,可能会觉得这种分类,分层简直是完美无缺的;但如果和C/S的开发模式进行对比就会发现,这种强制性的分层,其实是人为将原来的一件事情,分成三个层次来解决,然后每个层次再加上额外的解决方案的一个解决方案. 或者说,所有这些问题,本来可以根本上就不存在,但你生生制造出这么多问题来,最后再发明出一个解决方案来解决这些问题.在解决的过程中带来的新的问题,于是再发明一些新的方案来解决这些问题. 以前有个笑话,说某人找了个媳妇,在和面,面多了,就加水,一会儿水多了,就加面,于是乎事情越来越多. 现在的Java Web开发,正走向这样一条不归路,发现一个问题,就发明一个新框架来解决,于是又带来新的一个问题,于是又发明另一个框架来解决. 现在Java Web开发的一个怪现象是,程序的代码不少,但和业务有关的没有多少, 相反是框架相关的层出不穷. 所有这些问题的根源,我看就出在强制性的分层上. 界面层,业务逻辑层,数据访问层的划分并没有问题,问题在于分层以后,是否一定要把他们拆分到不同的代码段来实现,是否一定要把这些当成完全不同的问题来采用完全不同的药方来解决. 既然在C/S上这三个问题可以简单来用一个语言,一个方案来解决,为啥B/S的开发一定要分开处理,搞的大家疲劳不堪呢? 4.3技术框架上的皮之不存,毛将焉附关于技术,语言上的是是非非,实在不是一两句话能够说清楚的事情. 前两天在和朋友的交流中,忽然想到这样一句话:皮之不存,毛将焉附,以此来形容很多技术的兴衰,真是非常贴切. 所有的技术,语言也好,框架也好,其实都有一个基本的假设,在讨论问题的时候,往往是在这个隐函的前提下来讨论才得出的结论,一旦经过认真考虑,把这个假设推翻了,那么整个技术的大厦也就轰然倒塌了. 以下举例说明. 譬如J2EE架构,在早期推出的时候,强调EJB这一组件的功能,其实隐含了一个假设:所有的应用都需要分布式支持,所以才提出EJB这样一个分布式的技术方案.后来在实践中终于发现,绝大部分应用都不真正需要分布式支持,于是乎EJB就变成了J2EE中著名的鸡肋产品.甚至基于这个观点,推除了J2EE without ejb这样的概念出来.此其例一. 譬如JSP技术,按其本名,Java Server Page,就是利用Java语言在后台服务器上,动态生成一个Page的意思.这里其实有两个隐含的假设,其一,页面是动态生成,而且是用Java动态生成;其二,页面是在服务器上生成,而不是在客户端生成.在技术发展的早期,这一概念确实风靡一时.但在目前的技术生态中,增加了Ajax和RIA的概念,在RIA的概念中,页面完全是可以由客户端来动态生成的,这种情况下,就把JSP存在的基本假设推翻了,长此下去,JSP技术的立足点就不复存在了. 再譬如Jsp的tag技术,它的基本假设是采用JSP技术来做页面展示,一旦上面第二条中谈到的假设 被推翻了,jsp的tag技术也就没有立足之地了. 譬如Hibernate技术,它的隐含假设,就是对于数据库的操作,必须通过对象方式来实现,不能直接编写SQL语句,一旦这一假设不存在了,Hibernate的用处也就不存在了. 譬如Spring技术,它的隐含假设,就是所有业务逻辑及数据处理等等,都集中在服务器上进行,而且这些组件还是经常要改变的,所以为了管理方便,给你搞一套IOC的玩艺儿来试图简化它. 但如果这些假设都不存在了,要Spring干啥用呢? 这样的例子简直举不胜举. 大家在疯狂的讨论技术的种种优势和缺点,但是在讨论这些问题之前,请先明确一下,所有这些讨论,它的假设是什么,它的前提是什么.4.4 J2EE系统架构的致命缺陷关于j2ee系统的是是非非,已经有无数的口水了, 实在没有必要增加更多的口水. 昨天忽然想到,这个系统的整体架构,其实有一个很大的缺陷. 这个缺陷就是,j2ee的架构中,对于最终的客户端,是假设作为哑终端来存在的,除了显示一个界面以外,基本上啥也不能干. 这是整个j2ee架构最基本的理论基础.正是基于此,才有了各种各样的细分技术方案,组合起来形成一个j2ee的理论体系. 后来的javascript其实是不包括在这个体系之内的,而且随着在客户端开发的增加,再逐渐增加了各种各样的框架进去,其实是对原来的那个基本假设的一步一步否定. 如果客户端不再是一个哑终端的话,那么整个j2ee体系存在的合理性就不复存在了. 所以java这个阵营的,都在拼命在服务器方面下功夫,对客户机尽量不动.而这造成了很多的无用功. AJAX出现以后,事情逐渐发生变化,客户端的开发热了起来. 于是就有了jsf这种世界上最奇怪的技术出来,明明可以在客户机上做的事情,非要到服务器上去做,你说这是何苦来着? 4.5 Hibernate是垃圾我个人的观点,Hibernate这种东西纯粹是垃圾. 看到这里有人要跳脚了,这么高级的东西,你岂敢污蔑于它. 且慢着急上火,先冷静下来,这个观点是我最近重新研究VB这种古老的语言,才得出的结论. 在VB的世界里面,是没有所谓的ORM这种东西的,相对应的,有ADO Data控件,你只要给这个控件一个SQL语句,它就会自动和数据库建立关联. 包括表,字段这些都可以,以后的修改只要把Ado里面的数据改了,就可以自动更新到后台数据库去. 在一个没有所谓ORM的世界里面,写程序不仅是可能的,而且更加简单,更加方便. 现在回顾一下Hibernate要解决的问题是从那里来的,根本的原因就是Java语言教条的把一切都看成对象,万事万物皆对象,走火入魔的结果就是把数据也看成了对象,因此必须把数据库的数据映射成一个对象,一个对象集合才能理解,才能操作,否则就觉得不够爽. 其实何必呢?数据就是数据,为啥非要自找苦吃,先把它转成个对象,然后操作这个对象,然后再把这个对象变成数据,为了这种复杂的转换,最后还要发明出一个ORM的工具,来试图简化这个ORM的过程. 如果这个ORM的过程根本上就是不需要的,那么又何必存在Hibernate这种东西呢? 既然在十年以前的大量软件实践中,已经证明没有ORM这些怪异的东西照样可以写出很复杂,很强壮的程序,为啥一定要在系统里面加入这些怪物呢? 我之所以说Hibernate是垃圾,理由就是它在试图解决一个原本本来根本不存在的问题,而在解决这个问题的同时,自己又变成了新的问题. 4.6为什么J2EE如此低效-用户无法参与开发关键字: j2ee 论坛访问地址(有回复,已经隐藏)/topic/395549 这是从网上搜到的一个J2EE的定义. J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如编写一次、随处运行的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。 J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise JavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。原始的连接在这里: /developerworks/cn/java/j2ee/ 问题是:出于如此美好目的设计的技术,最后为何会变得如此低效,如此难以开发,难以维护呢? 原因当然是很多很多了.不同人有不同见解都是很正常的.要把所有原因分析讨论完,怕是用尽所有的时间和硬盘也是不够的. 在我看来,其中一个很重要的原因,就是在J2EE的整个开发维护过程中,在项目的整个生命周期里面,用户的作用被忽视了,在整个J2EE的设计思路里面,根本没有考虑过最终用户将如何参与到整个系统的开发,设计,使用,以及后续的运维中来. 这才是J2EE整个理论体系的最致命缺陷.虽然目前随着RIA应用的推广,J2EE本身也在进行着演化,但到目前为止,整个理论体系仍然没有突破这一限制. J2EE本身的基本理论基础,是以服务器为中心的设计思想,一切工作都在服务器上来完成和实现.客户端是为服务器来服务的.在J2EE的整个理论体系里面,没有考虑用户界面应该如何优化,也没有考虑用户的实际体验将是怎样的.J2EE关注的重点和核心是后台的服务器. 作为一个理论体系,J2EE是完整的,也是相当复杂,难以全部掌握的. 在实际项目中,用户的参与是非常重要的,在项目的开发中,用户不仅给出建议意见,在后续的维护中,更是用户本身需要对系统的进一步发展演化来进行把关. 可以在J2EE的项目里面,用户想参与到项目的整个开发过程中来,实在是太困难了. 用户所能够理解和发表意见的部分,在整个项目里面,是用户的界面部分,操作的流程部分.这一部分,本身也是用户日后使用中实际接触的部分. 而按照J2EE的开发模式,绝大部分精力都花费在了中间层的J2EE技术上面,不同J2ee服务器之间的差异,各个开源框架之间的协调,各种技术bug的处理.所有这些把开发人员的时间和精力全部耗尽了,根本没有余力来和用户讨论界面该如何组织,操作流程如何优化. - 问题的另外一个方面,就是基于j2ee的开发模式下,界面的开发实在是太过困难了. 一旦你采用J2ee的技术架构,前台的用户界面,几乎都选择采用HTML语言来编写,这样的选择也不难理解.J2ee刚出来的时候,当时只有HTML和Applet可以选用,当时javascript还没有发展到今天的地步.一旦你的技术团队选择了java语言,其他方向的技术人员自然也就不在考虑范围之内了.大家都用HTML来写页面了. 但问题是,HTML语言来编写应用程序的界面,实在是太困难的一件事情. - 如果只使用标准的HTML语言,不使用任何的样式表的话,那么这个界面实在是太难看了. 而使用CSS的话,写这样的界面又增加了新的困难程度. 对了,现在还没有说JavaScript呢,在页面上增加javascript,在增加页面功能的同时,也增加了页面长度,这些增加的代码,对于以后的系统维护,都是一颗颗地雷,后续者必须以百倍的热情和谨慎,才能不被这些地雷炸伤. - 上面的讨论还是仅仅是在技术层次上进行的,其实还有更重要的一个方面没有谈到. 这就是界面开发上的所见即所得.由于Web界面开发的复杂性,没有一个开发工具可以实现真正的所见即所得,只能在运行的时候才知道最终的结果到底是怎么样的. 在这种情况下,除了增加开发的复杂度以外,用户也就被排斥到了整个开发过程之外. 用户没有办法对界面提出自己的要求,一是这种要求会被回应:对不起