《基于J2EE架构的企业应用开发新思维》由会员分享，可在线阅读，更多相关《基于J2EE架构的企业应用开发新思维（40页珍藏版）》请在金锄头文库上搜索。
1、基于J2EE架构的企业应用开发新思维基于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 J
2、2EE系统架构的致命缺陷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设计思路356.1.2.1 WebDW释义356.1.2.2 WebDW的设计理念366.1.2.3数据窗口对象说明376.1.3 界面示意图（同一个界面文件，VB，Java，Flex版本不同实现）386.2其它可
3、行的技术方向396.2.1跨越语言和平台的鸿沟397结束语401前言在企业级的应用系统开发领域，J2EE架构现在已经被普遍接受了。虽然它并未完全兑现刚刚出现时的种种美好许诺，跨平台，分布式，易于开发维护等等，但J2EE的广泛普及，已经是一个不争的事实。虽然J2EE已经非常普及，但从技术上来讲，它本身还是存在很多缺陷的，比较突出的缺点，就是开发效率低，维护更加复杂，许多项目组都陷入其中不可自拔。本文将就造成这一现象的原因进行初步探讨，并在此基础上提出自己的解决思路。本文讨论的范围仅限于采用B/S开发企业的应用系统，不涉及网站类型的应用开发。讨论的技术方向，主要针对J2EE，其余技术方向不作为重点
4、讨论，仅供参考。本文先从Web开发的现状困境开始，分析造成目前困境的原因，然后通过回顾B/S技术架构的演化，以及对比C/S和B/S的开发模式的差异，提出一套新的开发解决思路，最后介绍WebDW系列产品的设计目的和简单功能，再以此为基础来进行扩展讨论。2 Web开发的困境2.1概述说明：Web应用系统的开发，像一座大山一样，把所有的人都压垮了。自互联网出现以来，企业应用系统的架构发生了很大的变化，C/S架构被废弃，B/S成为绝对的主流。但B/S架构本身，要比C/S复杂的多，加上新技术层出不穷，整个行业都处于巨大的困境之中。Web应用系统的开发，就像一座大山一样，把所有的人，无论是甲方还是乙方，无
5、论是开发人员，维护人员还是系统用户，都被累垮了。2.2Web系统开发的复杂性B/S系统本身的架构设计，要比C/S系统复杂很多，在C/S架构中，一般是两层结构。如下图。一般在这种架构中，服务器是一个数据库服务器，只负责数据的存储和读取访问支持；前台程序采用 VB，PB，Delphi 等图形开发工具来开发，通过网络直接连接到后台的数据库服务器，通过发送SQL 命令来实现数据库的访问。这种开发环境下可以使用图形化的控件来搭建用户界面，用户的交互性比较好。缺点在于应用程序发布在客户端，如果客户机数量很多的话，客户机程序的安装，升级都比较困难。而在B/S结构中，涉及到了多种服务器类型，Web服务器，Ap
6、p服务器，DB服务器。如下图。在B/S系统中，用户通过客户机上的浏览器来访问后台的Web服务器，Web服务器再把相应的请求转发给应用服务器来处理，应用服务器再将其中的数据访问请求转发给数据库服务器进行处理。在C/S系统中，应用系统或者应用程序本身是一个完整的，独立的整体，一般采用一种开发语言来开发即可，这种开发语言不仅负责用户界面，也负责业务逻辑控制，以及数据访问请求的生成发送，主要的开发和执行工作是在客户机上完成的。而在B/S系统中，整个系统的架构要复杂的多。首先，客户机上只有一个通用的浏览器，用户操作界面是通过Web服务器返回的HTML语言来进行描述的，如果需要一些动态特征，则不得不通过在
7、HTML页面中嵌入JavaScript来实现。在应用系统中，大量的页面是动态，而非静态页面，因此必须在应用服务器上完成动态页面到静态HTML的转换工作。如果动态页面中包含数据访问请求，则又必须访问后台的数据库服务器来协助完成此项工作。以J2EE标准流程为例，当用户在浏览器上输入一个地址，或者URL以后，这个URL首先传递给Web服务器，然后再转发给App服务器来解释执行。假如请求是一个jsp页面，应用服务器首先读取这个文件，然后把它翻译成一个java文件，再编译成一个class文件，再解释执行这个class文件，如果需要再访问后台数据库，最后产生一个HTML格式的输出文件流，返回给Web服务器
8、，再返回给客户机浏览器解释成一个界面。与C/S开发的一种语言包打天下不同，B/S系统的开发需要在多个层次上进行编程开发：浏览器中，用HTML和JavaScript编程；应用服务器上，用Java或者.net之类编程，数据库服务器上用SQL语句编程。在C/S开发中，最终的产品是一个Exe文件；而B/S开发中，最终的产品是一个网站，里面包含成千上万个文件，而且是各种不同类型的文件：HTML,图片，JSP, Java, Class, XML等等。在Web开发中，人们为了简化开发过程，提高效率，陆续发明了很多新技术，在页面开发上，基于JavaScript本身，发明了如prototype, jQuery,
9、 Ajax等框架；基于java技术，发明了J2EE架构，基于J2EE架构，又发明了Struts, WebWork, Spring, Hibernate ,Itabtis等无数的框架产品。结果在试图解决问题的同时，这些产品本身又造成了新的问题。相对于C/S开发的单一开发工具开发，B/S开发要涉及到很多工具，语言和框架，这些工具，语言和框架，都是为了解决某一问题而设计的，而开发人员必须把这些目的不同的东西整合起来，才能搭建出一个整体的系统。B/S的复杂度，很大程度上是由于涉及的技术面太多，太多的产品，太多的技术，太多的框架，这样不仅增加了学习的难度，增加了学习技术的成本，而且也增加了系统运行维护的
10、成本，最终提高了整个系统的开发，运营成本。这种高昂的成本让开发人员，维护人员，开发公司，和甲方都陷入了困境之中，大家在这一困境中挣扎，不能自拔。2.3开发人员的困境在B/S系统的开发中，开发人员是最辛苦的一类人。用户的所有需求，都需要一行一行编写代码来实现，项目时间紧，加班加点干，最苦恼的是，要完成一个基本的功能，需要学习一大堆东西才能实现。HTML, JavaScript, Ajax, Jsp, Servlet, EJB, Jdbc, Struts,Spring ,Hibernate,光是技术名词，恐怕一张纸都列不完。开发人员面临的困境，就是技术本身在快速演化发展，不时有新名词，新概念出现，
11、同时现有的技术也在快速演化之中，真是生也有涯，而知也无涯，感觉象夸父追日一样，每日不停的奔跑追赶，何日才是尽头啊。另外一个头疼的事情，就是技术架构的变化性，今天一个语言，明天一个语言，一旦底层的平台变了，自己费劲力气学会的东西就一文不值了，年龄一天一天大了，那里有那么多的精力老追赶新技术呢，于是很多人转行离开了。但仔细想一想，所有这些架构，这些技术，真的那么必要吗？为什么一定要忙于学习新的技术，而不是把精力用在用好现有的技术上呢？为什么一定要受限于某种具体的语言和技术，而不是采用跨语言的解决方案呢？为什么一出现新的技术，就把原来的代码全部推翻重写呢？为什么要用这么复杂的架构来实现原来一种语言就
12、能实现的简单功能呢？譬如，以非常流行的Hibernate来举例说明，Hibernate的设计目的，是简化ORM过程，使得数据库的数据表可以容易的映射成一个Java对象。但问题是，为什么一定要把数据表映射成一个Java对象呢？如果这种映射本身就不是必须的，那么Hibernate试图解决的问题，原本就是一个不存在的问题，那么这个产品的价值又何在呢？以我的观点，Java世界里面这么多框架，产品，语言，很多都是这样的思路，不是在试图解决问题，而是在不断的创造新的问题出来。开发中用的产品，技术越多，系统就越复杂，光是学习这些技术，框架怎么使用，就把开发人员的时间和精力耗去大半，而究竟应该怎样来设计实现系
13、统，已经没有人考虑了。时间和精力被无谓的消耗掉了。这才是开发人员最大的悲哀所在。Web开发压垮的第一批人，是开发人员。压垮他们的，是系统的复杂性。2.4维护人员的困境终于，在多次延期，多次修改，无数次补丁以后，系统终于上线了。现在轮到维护人员来面对这个庞然大物的系统了。系统维护人员，对自己的工作，有一个形象的，不太雅观的比喻：擦屁股。系统本身开发起来就复杂，使用起来也复杂，再加上开发过程中隐藏的错误，行业术语叫Bug，维护人员的电话一直没有停过，除了操作指导，就是错误报告，再加上误操作以后直接在后台数据库里面改数据，反正事情又多又杂，整天忙得不亦乐乎。如果是开发人员自己来做维护，相对还好一点，
14、至少里面是怎么回事情，大概知道个差不多，有了问题，小修小补打打补丁，虽然累点，总还是有希望的；如果不是自己开发的，要来做维护，那就要了老命了，要文档没文档，要注释没注释，还要面对同样多的技术架构，语言和技术平台，用维护人员的话说，就是如履薄冰，如临深渊，每天都在祈祷，这个系统别出问题。从表面上看，是开发人员和维护人员之间的矛盾；从本质上看，是系统复杂度的矛盾。如果一个系统开发的很复杂，那么它本身就很难维护，即使勉强维护，维护的成本也很高。如果你在系统里面用了10项技术，那么维护人员就必须学习10项技术才能进行维护；如果你在系统了写了10万行代码，那么维护人员就必须面对10万行代码。当维护人员觉
15、得系统已经无法支持下去时，他们会一走了之。而新来的人对于这个系统，工作的难度只有更高，更加难以胜任。当一个系统无法维持正常的维护时，它的寿命也就到了。这时就会把它推掉，重新开始一个新的系统开发。不幸的是，新的系统一般来说会重复旧系统已经走过的路线，开发的更加复杂，更加难以维护，最后再次陷入无法维护的境界。为什么系统变得难以维护，因为系统太复杂；为什么维护人员无能为力，因为系统太复杂；为什么维护成本居高不下，因为系统太复杂；Web系统压垮的第二批人，是系统的维护人员，压垮他们的，还是系统的复杂性。2.5科技公司（乙方）的困境和对个人的收益不同，系统复杂性，带给科技公司的，既有收益，也有风险。系统复杂度的收益，就是客观上的跑马圈地，一件事情简单了，能做的人就多，竞争就激烈，最后就不好赚钱。CPU不是谁都能设计的，所以Intel发了；OS不是谁都能开发的，所以MS发了。把Web系统搞得很复杂，就会人为提高它的门槛，能做的公司少了，竞争就会少很多。早期的C/S阶段，把整个MIS系统搞得很简单，开发门槛太低，于是有一大堆的公司来做，最后大家都难以生存下去，现在的外包公司，也不需要公司有啥技术积累，于是有一大堆公司一起做，最后大家都挣不了钱。从这一方面来说，系统搞的复杂一些，对科技公司来
