什么叫把企业应用逻辑绑定到Servlet框架呢？ 所谓绑定，就是直接在结算管理软件开发中处理业务逻辑，例如，计算保险代理人的佣金，或者把框架中的Request参数传递到业务逻辑计算之中。在软件开发实践中，这样的错误用法屡见不鲜。我将反复强调这个问题。

正的做法是，为了确保企业应用逻辑的可移植性，我们应该把Servlet框架作为企业应用逻辑提供者与使用者之间的桥梁，而不是把Servlet框架作为企业应用逻辑的一个不可分割的组成部分。 

基于结算管理软件开发框架，业界完善了动态Web应用程序的想法。一个动态Web应用程序可以独立发布和部署，如果再加上数据访问的功能，它已经可以作为一个简单应用系统的架构级方案了。不过，对于稍大规模的应用系统来说，单纯的Web应用程序框架就显得过于简单了。有一些技术，可以充实这类稍大规模的应用系统架构，例如，基于MVC架构模式的Struts框架和实现OR Mapping功能的Hibernate框架。Struts框架把动态Web应用程序中的代码做了功能性的抽象和划分：有的代码属于对象模型，有的属于用户界面，还有的属于逻辑计算。经过这样的划分，程序结构显得更加符合“模式化的想象”（隐喻）。 

模式化的想象使人们的思维变得清晰和具体。这也是所有架构的本质。当然，模式抽象只是Struts框架的一部分。和所有的框架一样，基于模式抽象，Struts框架还提供了一些约束性的编程模型，例如，页面流转配置、Tag库、Action映射等。 结算管理软件开发框架解决的则是OR Mapping问题。这也是面向对象开发的一项基础技术。关于OR Mapping及Hibernate框架，读者可以去阅读相关的书籍。让我感慨的是，在软件开发实践中，真正理解OR Mapping的人真是太少了。

我看到有很多人在抱怨OR Mapping框架的性能。他们一面抱怨，一面转而选择JDBC来直接处理数据访问，这是一种严重的错误。在下一节中，我会列举一个反面的例子，你会明白这种想法是多么的失败。 加入上面两个架构元素之后，动态Web应用程序看上去比较丰满了。可是，在处理真正的企业级应用系统的时候，这种级别的架构就远远不够了。不够的意思，不是说不能，而是说，这种架构提供给应用结算管理软件开发的支持太少了。例如，订单协同软件没有分布式计算的支持、没有事务的支持、没有安全的支持、没有异步消息处理的支持，等等。这时候，业界出现了J2 EE规范，以及基于J2 EE规范的各种框架。 支持J2EE全部规范的框架，通常是个重量级的框架，它几乎实现并提供
了企业应用所需的所有服务（目前，Struts和Hibernate技术框架的思想，也被纳入了Java EE规范之中——JSF和JPA）。