上周在 SpringOne 上，Alef 和我做了一个关于使用 Spring 处理复杂应用程序的演讲。这里所说的复杂性是指结构和动态两个层面。关于结构的讨论，我在我的 之前的博客文章中已经介绍过了。动态部分解释了一些可能的解决方案来处理您的部署环境之间的差异。（测试、验收、生产等）很多人问我是否可以提供我在演讲中给出的演示源代码。我将源代码附加到这篇博文中，并简要解释一下这一切是如何工作的。希望这次谈话最终会在今年晚些时候在 parleys.com 上发布，这样您就可以获得更多关于该主题的背景信息。

环境感知：支持您的运行时环境

在演讲中，我认为通过使用自定义构建脚本来生成每个环境的部署单元来处理环境之间的差异存在一些缺点。其中之一是，当您的应用程序从例如您的验收环境提升到生产环境时，您无法重用您的构建工件（war 或 ear 文件）。为了解决这些缺点，您必须使您的应用程序环境感知：想出某种方法来确定您的应用程序在什么环境中运行，然后配置您的应用程序以对此做出反应。

有很多方法可以做到这一点：在一个 Spring 应用程序中，启用依赖于环境的行为的显而易见的方法是为每个需要非默认配置的环境设置不同的 Bean 定义。我已经展示了三种方法来做到这一点

• 第一种方法是为某些环境加载额外的上下文配置文件。通过使用 Bean 定义 继承和覆盖，您可以在配置时采取适当的措施。当您使用 ContextLoaderListener 来配置您的 Web 应用程序上下文时，这需要一些额外的代码，这些代码在附加示例的 Web 项目中显示。顺便说一句，这个想法应该归功于我以前的同事（Ezra，谢谢！）
• 第二种方法是使用 JavaConfig 而不是 XML 来定义您的依赖于环境的 Bean。您确定创建哪些 Bean 的位置，然后从确定要加载哪些配置文件移动到您的 JavaConfig 类。
• 最后一个示例将前两个示例组合在一起，以确定要使用哪个 JavaConfig 类，其中为每个环境创建扩展通用基础配置的子类。这展示了在实际类中进行配置的强大功能：您可以使用常规 Java 继承和多态性，这模糊了 Bean 定义继承和类继承之间的区别。

其他方法可以包括自定义的 FactoryBean-实现，例如。

示例

这些示例演示了使用一个简单的服务和 DAO，通过名字查找一个人的姓氏。在默认情况下，只定义了两个人（Alef 和我）。在开发环境中，我们将使用静态的 DAO 实现，它总是返回一个 John Doe。在验收环境中，定义了第三个人（我们的同事 Arjen）。集成测试检查我们的应用程序在每个环境中是否公开了正确的行为。

有很多方法可以检查您的应用程序在什么环境中运行：对于这些示例，我使用了 EnvironmentUtils 类正在使用的系统属性。其他方法可能是检查数据库或 JNDI 注册表，例如。

我没有简单地压缩我的 Eclipse 工作区，而是创建了一个 Maven 示例更新: Dave Turanski 友善地 更新了该示例 到 Spring 3.0：在几年前我厌恶地放弃 Maven 后，最近有几个人试图说服我再次尝试 Maven。我不得不承认，Maven 2 实际上比 Maven 1 好得多，尽管 Web 项目的 Eclipse 工作区工件的生成还有待改进（例如 WTP 2 支持）。我也错过了一些其他的东西，但这可能只是我完全缺乏经验。好处是，我现在不必将所有依赖项打包到我的示例中。

安装 Maven 后，您可以通过从根目录运行“mvn test”来运行示例测试。要从示例中生成 Eclipse 项目，请运行以下命令：“mvn -DdownloadSources=true eclipse:eclipse”。要构建 jar 和 war，请使用“mvn package”或“mvn install”以将构建工件添加到您的本地存储库。

war 包含一个可以作为“/[context-root]/env”访问的 servlet：要查看每个环境的差异，请使用一个名为“app.env”的系统属性启动您的 servlet 容器，该属性保存环境字母（D、T、A 或 P）。因此，添加到服务器启动行的 -Dapp.env=D 将导致应用程序在开发模式下运行，这意味着返回的所有姓氏都将是“Doe”。