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，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。
问题是:出于如此美好目的设计的技术,最后为何会变得如此低效,如此难以开发,难以维护呢?
原因当然是很多很多了.不同人有不同见解都是很正常的.要把所有原因分析讨论完,怕是用尽所有的时间和硬盘也是不够的.
在我看来,其中一个很重要的原因,就是在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界面开发的复杂性,没有一个开发工具可以实现真正的所见即所得,只能在运行的时候才知道最终的结果到底是怎么样的.
在这种情况下,除了增加开发的复杂度以外,用户也就被排斥到了整个开发过程之外.
用户没有办法对界面提出自己的要求,一是这种要求会被回应:对不起,做不到.对不起,难度太大.二是在整个界面的开发过程中,用户本身是隔离其中的,用户无法真正理解界面开发的全部过程,也就无法提出合适的意见出来.
-------------------------------------------------------------
这种将用户隔绝在界面开发过程的恶果,就是用户对最后的界面,包括观感,包括操作流程,都不够认可,于是经典的软件工作模型开始了.
开发人员开发出版本1--->用户提出修改意见1-->版本2--->意见2--->版本3--->意见3
整个循环在项目数次延迟以后勉强结束.
我们满足用户的需求了吗?没有.
为什么会有这么多次的反复呢?因为从一开始,开发者就没有合适的途径来接收用户的反馈意见,只有把所有界面都完成才能开始接收用户的界面反馈.因为没有合适的机制,让用户来参与到整个项目的开发过程中来.
--------------------------------------------------------------
J2EE这个技术架构的致命缺陷,就是没有考虑到用户的参与,它关注于如何建立一个理想的技术乌托邦,而没有考虑在现实的世界里面,没有客户的认可,整个技术框架都是空中楼阁.
--------------------------------------------------------------
任何的讨论,都是有一个对立面存在的.
与J2EE相比,我选择的参照物是Visual Basic(不是vb.net).
VB的最大优点,就是所见即所得,这个界面开发的过程,非常直观,非常简单,也非常容易理解.因此在VB的开发里面,用户是完全能够理解这个界面开发的全部过程,也能够提出具体的修改意见出来的,甚至在培训以后,由用户自己来绘制一些界面和调整一些界面是完全可能的.
正是因为如此,采用VB这类工具开发的过程中,至少在界面这个层次上,修改是可控的,用户对最终的界面是很容易认可的.
而在J2EE里面,事情就不是这样了.
【编辑推荐】
