j2ee应用中有一些常见的毛病和错误的观念，按照时下流行的说法，叫反模式。稍不注意，我们自己也会犯，所以大概整理一下，一个是备忘，也是供需要的朋友参考：xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
ejb一直发展到今天的2.1仍然被广为诟病，它提供了很多时候我们并不需要的东西，而且我们在很多情况下一旦选用ejb就没有其他的方式不去使用那些笨重的功能。但是很多所谓范例让我们有一种错觉，好像不用ejb就不是j2ee应用。有一些折中的方案是使用session fa?ade模式，entity bean采用bmp + 本地接口，然后提供一层无状态的session bean，采用远程和本地接口，这样的设计模式，我想，多半是出于无奈。如今，甚至我们经常都能看到不使用ejb的言论，炒得很火的spring则为这种完全不用ejb开发j2ee项目提供了实际的、强有力的佐证。
2- 过度分层
j2ee这个规范肤浅的来看，就是为我们定义了很多“层”，然后还有很多分工明确的“角色”，加上j2ee的蓝本应用程序就分了很多“层”，以至于大家都觉得j2ee的应用就应该是很多层的，其实不然，需要具体情况具体分析。
3- 频繁的往返调用
ejb的看似简单造成我们经常忽略可能在使用过程中出现的远程调用，比如有时候为了更新一条记录，每个字段都是远程的去set，大大增加了不必要的开销，于是我们意识到在调用中使用dto是一个建议遵循的方案。
4- 过度使用有状态的session bean
一般来讲，一个session bean实例，如果它是有状态的，那么它只对某个固定的用户服务，如果是无状态的，则可以满足不同用户的调用。这有点类似（只是有点类似）一个类的静态方法和非静态方法的区别。我们在实际应用中，应该尽量避免使用有状态的session bean，除非特别必要。我们可以把状态保留在session bean之外，如web容器的session对象或者我们自定义的类中，而不是完全依赖有状态的session bean去帮我们做。
5- 过度会话
web容器的session对象是个好东西，用起来也很方便和直截了当，这造成了我们很多人对它的滥用，什么东西都往里面放。这有两个突出的问题，一个是资源浪费；另一个，万一web服务器崩溃，那些本来需要持久化的数据就丢失了。我们需要考虑好，哪些数据本可以用request的，哪些数据又是需要持久化到数据库的，等等，不能一味依赖session。
j2ee为我们提供了web层丰富的技术选择，servlet或者jsp都只是其中一种，虽然它很强大，但是也不应该由它一个来承担所有mvc三个部分的功能。现实中我们的struts很好的规范了这个问题：servlet负责调度，专门的action负责处理逻辑，而jsp用于用户界面显示。jsp和servlet本质上是同一个东西，只是从不同的角度来处理问题，它们各有所长，互为补充。
Java Asp PHP .Net XML C/C++ CGI VB Jsp J2ee J2se J2me EJB Servlet Tomcat Resin Struts Weblogic Eclipse ANT GUI JMS Web servise IDEA Webphere Hibernate Spring Jboss Applet Swing Socket Javamail Perl Ajax P2P 安全 模式 框架 测试 开源 游戏
Windows XP Windows 2000 Windows 2003 Windows Me Windows 9.x Linux UNIX 注册表 操作系统 服务器 应用服务器
