架构反模式
这些反模式广泛地出现在应用程序架构中。
重新发明轮子
这个术语不需要任何解释。在开发软件的时候，一般有两种选择--在已有的技术上建立或者从草稿开始。尽管在不同的情况下，两者都可能适用，但是在重新发明轮子（为了满足需求，重新开发已经存在的功能或函数）之前分析已有的技术仍然是有用处的。这可以节约时间、金钱，并提升开发者已有的知识水平。
厂商的锁定
当软件部分或整个依赖于特定厂商的时候会发生这种情况。J2EE优势之一就是其轻便性，但是它仍然赋予了厂商提供丰富的拥有版权（所有权）特性的机会。的确，在开发过程中，这些特性可能是有帮助的，但是它们有时也有负面作用。其中出现的一个问题是控制权的丢失。你可能非常熟悉和喜欢六个月之前的某种特性。另一个问题是，当厂商作出改变（修改）的时候，可能会打乱你的软件开发、降低协同工作的能力、强迫你持续升级等等。
解决这个问题的一种方法是在版权元素的上面提供一个隔离层。例如，Commons Logging就可以插入任何日志记录框架组件（例如Log4J或Java Logging）之中。
J2EE特定的反模式
表2列举了普通应用程序层的几个反模式。
表2：普通的J2EE反模式。这个表列举了J2EE应用程序的不同层次中出现的反模式。
层
反模式
持久层
捞网
窒息
JSP
对话数据太多嵌入的导航信息
Servlet
每个Servlet中都有公用函数访问优良纹理的EJB接口
EJB
大的事务在JMS中过多的查询
Web服务
假设SOA = Web服务
J2EE
硬编码的JNDI查找没有有效利用EJB容器
下面解释表2中列举的反模式。
持久层反模式
它出现在那些需要从数据库检索数据的应用程序所引起的一些有趣的挑战中。
捞网（Dredge）
例如，我们来考虑一下浅度和深度的数据查询。开发者一般喜欢在一个操作中执行昂贵的（深度）查找，载入的信息量超过了需要的信息，而不喜欢通过分部的（浅度）查找来检索必要的数据以供显示和生成报表。这种策略可以在某些情形中使用，但是如果我们没有仔细地计划，它很容易引起性能低下、占用大量内存的问题。
窒息（Stifle）
J2EE应用程序包含了几个网络资源之间的交互操作--数据库就是其中一种。当应用程序与数据库交互操作的时候，我们就应该调整它，只让它消耗最合适宜的网络带宽，否则就可能导致伸缩性的问题。如果没有优化数据库通讯的网络管道，软件应用可能遇到瓶颈，甚至于会阻塞网络本身。
JSP和Servlet反模式
JSP和Servlet开发的过程中也有一些反模式。
对话（Session）数据过量
对于开发者来说，把JSP对话作为通用的数据空间是很有诱惑力的。对话为我们存储那些传输中的数据提供了一种简单的机制。但是网站访问量和相应的对话数据的增长可能引起崩溃。同时，粗心地使用对话可能导致键冲突，引发应用程序错误。更糟糕的情况是，可能出现跨越多个对话的共享数据错误（本来不应该共享的），可能导致敏感的用户信息泄漏。
即使没有这些技术问题，让对话不断"膨胀"也不是好的想法。对话数据应该限制在一定的范围中，只用于存储那些跨越多个用户界面的工作流所必要的数据，当那些信息不再需要的时候，就应该被清除掉。
嵌入的导航信息
当开发者硬编码（hardcode）或者向其它的JSP嵌入链接的时候可能会发生这种情况。如果页面的名称改变了，就必须搜索和改变其它页面中的所有相关的链接。我们必须在开始的时候就慎重地考虑导航方案，才能避免在后面的维护阶段出现"梦魇"。
每个Servlet中都有公用函数（功能）
在应用程序的多个servlet中经常出现硬编码函数（功能）会使应用程序难于维护。作为代替，开发者应该删除servlet中重复的代码。请使用一个框架组件（例如Struts）提供简单的、在XML文件中指定工作流程的途径（我们可以更改这个文件而不需要改变servlet代码）。还有其它一些工具，例如前台管理员（Front Controller）和过滤器也可以在一定的程度上移除硬编码。
访问优良纹理的（Fine-grained）EJB接口
在通过网络进行远程调用的时候，数据的列集（marshaling）和散列（unmarshalling）操作可能引发应用程序中主要的时间延迟。多重远程调用也可能引发延迟。根据应用程序的不同需求，其解决方案可能包括重新设计EJB，但是如果这不是问题的起因，servlet可能无法通过优良纹理的API来访问EJB实体。如果该EJB同时暴露了优良纹理的和粗糙纹理的API，那么servlet就会用单个的粗糙纹理API调用来代替优良纹理方法的多个调用。
