轻量级方法的成功秘诀

依赖注入
最新一代容器称为轻量级容器，它们使用一个共同设计原理：依赖注入。 对这个简单思想来说，这是一个复杂的术语。依赖注入让您将对象和它所依赖的东西交给第三方。然后第三方创建所有对象并将它们绑在一起。比方说，称为 myDao 的数据访问对象需要一个称为 ds 的数据源。那么该容器会一同创建它们，并设置一个属性：
清单 1. 创建一个第三方汇编程序
myDao　=　new　Dao();
ds　=　new　DataSource();
myDao.setDataSource(ds);
当然，不创建这种第三方汇编程序的话，您也可以使用框架来做其他附加的工作（如提供配置支持）。Spring 框架、Pico 和 HiveMind 就扮演了这个角色。其他像 JavaServer Faces(JSF) 框架也利用了依赖注入。
面向对象编程
使用面向方面编程（AOP），您可以编写通用的功能性模块（称为方面） —— 例如，日志、事务、安全或持久性。AOP 使您可以将这些方面联系到 POJO，然后指定一个时间点（如方法开始时或产生异常时）和另一个需要联系的方面。例如，您可能想要创建一个外观事务对象。您可以在调用方法时将 TransactionBegin 方面关联到外观方法。然后在产生异常时将 RollBack 方面关联到外观的异常。最后，在方法结束时将 Commit 方面关联到外观的方法。您在配置中完成这些工作，而不是通过编写代码。依靠这种能力，您可以创建一个简单的 POJO 事务、安全或远程访问。
您现在已经得到了关于 POJO 的声明性事务，这对企业应用程序非常有用。使用这些工具，您可以完全放弃 EJB，或者最小化它的作用。而这正是轻量级组件所要做的。
透明持久性
持久性也是建立在较简单的编程模型之上。透明持久性框架通过配置而不是编写代码，来使您为应用程序添加持久性。因为大多数应用程序是面向对象的，并且访问一个关系数据库，所以一些专家断言，我们最终将进入对象关系映射的时代。我目前发现的顶级持久性解决方案是 SolarMetric 的 Kodo JDO 和 Hibernate。在后面的文章中我将详细比较这些解决方案。其他轻量级解决方案，例如 iBATIS 和 Active Record 设计模式，根本不会试图进行对象关系映射。 Java 行业经历了类似的情况。EJB 技术提供了核心的企业服务。如果您曾对一个复杂的、基于组件的模型编程，您会将业务组件放入一个容器中，该容器提供诸如事务、远程控制、安全和持久性之类的服务。
然而，这里存在一些开销。重量级架构对于解决许多问题都过于复杂。例如，实体 bean 会让您为每个实体编写 7 个文件。因此 EJB 技术就不值得用来解决日常问题。如今，许多业务仍然需要企业服务，但它们正在寻找达到该目标的新方向。它们使用轻量级容器。实际上，最新的 EJB V3.0 标准就使用了轻量级容器模型。
什么是轻量级容器？
大多数容器 API（如 EJB API）强迫您编写一些接口或一个组件模型。将您的组件放入该容器后，容器会为您处理一些事情。EJB 容器提供企业服务。Servlet 容器（例如 Apache Jakarta Tomcat）实现了 Servlet API，使您可以将动态内容建立到服务器页面中，该页面随后会被发送到 Web 浏览器。
传统容器强迫使用指定的编程模型，轻量级容器则不是。它们使用普通 Java 对象（plain old Java object，POJO）。容器然后将 POJO 绑在一起，并将服务与它们相关联。 Spring 是什么？
您若是一名企业程序开发人员，Spring 会令您事半功倍。但它到底是什么？对于这样的综合性框架，很难轻易找到一个明确的答案。从本质上讲，Spring 是一个轻量级容器。您可以通过 Spring 来利用普通 Java™ 对象（POJO）编程，使用依赖注入解析 POJO 间的依赖性，然后使用面向方面编程（AOP）将服务与它们相关联。
Spring 也提供了许多胶水代码，这使您可以更加轻松地使用 Java 2 平台企业版（J2EE）服务，比如用于事务的 Java 事务 API （JTA）、用于远程控制的远程方法调用（RMI）、用于管理的 Java 管理扩展（JMX）或用于持久性的 Java 数据对象（JDO）。Spring 还为开放源码框架，比如 Hibernate、Tapestry、Struts 和 JavaServer Faces（JSF），提供了胶水代码。注意，虽然有些框架是相互竞争的，但这并不是什么问题，Spring 没有试图只支持一种获胜的框架。 本文介绍合力完成一种不同的活动：应用程序开发。敏捷开发流程，比如极限编程（Extreme Programming，XP）和 Scrum，寻求降低流程开销。尽管存在许多不同的流程，但它们当中都有一些共同的趋势：
越来越重视客户参与，而非重量级需求文档
通过重构改进质量和设计；重的、自动化的单位测试；连续集成
小团队，较少的正式沟通和更多的非正式沟通（15 分钟的站立早会，更多的配对编程）
短而一致的周期，最后是客户反馈
敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。尽管许多编程人员理解轻量级、敏捷方法的强大功能，但许多管理人员习惯使用更传统的流程。如果您认为敏捷可以帮助您，那么通过应用下列思想来学习如何协调传统管理与敏捷开发流程：
将您使用的语言改为侧重于原则，而非流程。
创建小而灵巧的团队。
重视可测量的交付。
重视简约性。
重构代码并自动化测试。
获得客户反馈。
原则而非教条
当编程人员或架构师试图将敏捷流程注入保守公司时，最好是抛开教条 —— 即，将重点放在原则而非教条上。如果您对 XP 的优点大肆吹嘘 10 分钟，典型的老板会关注一个词 极限。因为老板关注的是减轻风险，所以您注定失败。相反，您可以挑选一些您的管理层想要解决的问题。然后，选择敏捷原则来帮助解决这些问题。 本文介绍合力完成一种不同的活动：应用程序开发。敏捷开发流程，比如极限编程（Extreme Programming，XP）和 Scrum，寻求降低流程开销。尽管存在许多不同的流程，但它们当中都有一些共同的趋势：
越来越重视客户参与，而非重量级需求文档
通过重构改进质量和设计；重的、自动化的单位测试；连续集成
小团队，较少的正式沟通和更多的非正式沟通（15 分钟的站立早会，更多的配对编程）
短而一致的周期，最后是客户反馈
敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。尽管许多编程人员理解轻量级、敏捷方法的强大功能，但许多管理人员习惯使用更传统的流程。如果您认为敏捷可以帮助您，那么通过应用下列思想来学习如何协调传统管理与敏捷开发流程：
将您使用的语言改为侧重于原则，而非流程。
创建小而灵巧的团队。
重视可测量的交付。
重视简约性。
重构代码并自动化测试。
获得客户反馈。
原则而非教条
当编程人员或架构师试图将敏捷流程注入保守公司时，最好是抛开教条 —— 即，将重点放在原则而非教条上。如果您对 XP 的优点大肆吹嘘 10 分钟，典型的老板会关注一个词 极限。因为老板关注的是减轻风险，所以您注定失败。相反，您可以挑选一些您的管理层想要解决的问题。然后，选择敏捷原则来帮助解决这些问题。 选择合适的工具
对于带 i-drive（它投入更多的力量到踏板曲柄而不是弹起的后避震）的山地自行车、低容量的皮划艇（它让我使用河面下的水流）和框架，我有着相似的经历。当我的客户处理持久性时，为他们找到合适的框架可以把一个艰难挣扎的、沮丧的团队转变为一个运转良好的机器。但是，您必须小心。改变框架可能是昂贵的。本系列的 第 3 部分 展示了 Spring 如何帮助您优化诸如持久性（persistence）之类的服务。本文则关注寻找合适的持久性框架。首先，让我来破除几个神话。
神话 1：技术总是最要紧的。
不论您是在谈论 RDBMS 还是持久性框架，持久关系都是长期的。您需要知道您选择的方案将长时间拥有市场份额。如果不是，您将冒着被迫离开指定框架的风险，而这并非您的意愿。
神话 2：对象关系映射程序（Object Relational Mappers，ORM）隐藏了所有的数据库问题。
持久性框架简化了一些问题，但引入了一些其他的问题。如果您不理解底层架构，那么找懂的人问，或者不要使用对象关系框架。
神话 3：JDBC 总是比 ORM 要快。
当然了，一个非常协调的特定 Java 实现总是会打败普通的 ORM，但是您很难找到一个非常协调的 JDBC 应用程序。JDO 和 Hibernate 之类的框架提供许多方法来提升性能。
神话 4：ORM 总是合适的工具。
常常，您会发现要求更好的访问 SQL 的问题。您也会发现面向批处理的而非交互式的问题，或要求直接访问数据库行，而非完整的对象模型。这些问题并没有充分利用 ORM。更糟糕的是，一些解决方案也许会碍事。 在给 Java 技术飞艇戳几个洞之前，我应该提醒您一点儿历史。Java 编程语言来自一个没有希望的来源（Sun Microsystems），为了与控制服务器端的统治语言（C++）竞争，那时一个程序设计范例正在寻求摆脱困境的办法（过程客户端 - 服务器代码）。互联网爆炸，突然带有内置 Java 虚拟机（JVM）的 Netscape 出现在每个桌面上。为了被广泛接受，Java 语言向 C++ 社区做出了几个重大妥协：
像 C++ 一样，它是静态类型，而不是像 Samlltalk 那样的动态类型。
像 C++ 一样，它允许原语和对象。
它涵盖了 C++ 的语法和控制结构。
为了获得市场，Sun 保留了与 C++ 足够接近的东西来吸引社区。Java 语言没有必要比所有其他的面向对象语言都好。它只需比 C++ 好就行了。现在，其中的一些妥协开始损害 Java 语言。
闭包
Java 语言允许比 C++ 更高的抽象，比如管理内存和字符串。但是，要达到像 Ruby 或 Smalltalk 语言那样高的抽象，Java 语言还有很长的路要走。以迭代为例：用 Java 技术来完成一个数组的迭代，要这样写： 用 Smalltalk 编程？
Avi Bryant 使用 Ruby 编程语言创建了一个基于 continuation 的服务器，但是留下了 Smalltalk 的 Squeak 方言 —— 20 世纪 70 年代的初期，当 Ruby continuation 被证明是不太稳定（后来被修复）的时候，发明的一种纯面向对象的语言。然后他在 Smalltalk 的Squeak 方言上建立了 Seaside 框架并再未回头。他现在使用 Seaside 为客户快速地建立 Web 应用程序。他们愿意采用诸如 Squeak 之类的语言是因为这个框架的生产效率非常高，大大降低了开发的总成本，并提前了产品进入市场的时间。 使用 Java™ 编程语言进行 Web 程序开发与骑自行车这个例子有几分相似。我们总是把原本简单的事情复杂化。您需要确保一切无状态，才能获得更好的可伸缩性。如果以 Servlet 或 JavaServer Page（JSP）的形式为用户请求编写多种独立响应，就会留下许多散乱无章的独立请求/响应块。每个块都需要确定其在整个应用程序上下文中的位置。您必须绕过前进路上的每一块小石块，牢记各请求的状态。如果顾虑得过多，在用户单击 Back 按钮、打开第 2 个会话或者是尝试直接转到一个较旧的 URL 时，您会发现自己“从把手上方翻了出去”。您希望可以假设用户将按正确的顺序执行任务，但这显然是不可能的。绝大多数 Java 框架都不是以这样的方式运作的。
本文将向您介绍一种完全与众不同的 Web 服务器：基于 continuation 的 Web 服务器。当然，Java 编程语言没有为 continuation 提供内置支持（但其他编程语言有这样的支持）。这里，我将就基于 continuation 的服务器进行讨论。在 “轻量级开发的成功秘诀：第 8 部分” 中介绍了一种名为 Seaside 的此类框架，还介绍了一些可通过各类创新方式提供有限的 continuation 支持的 Java 技术框架。