问题标签 [spring]

我已经能够在业务服务类上使用 Spring AOP（结合 AspectJ 注释）定义多个方面（一个是 @Before，另一个是 @Around）。

目前，他们被一一（按顺序）调用。但是我想知道如何定义调用方面的优先级以及在哪里。

请就 Spring AOP 指导我。请注意，我使用的是 Spring 2.5.3 框架。

我有一个应用程序 - 更像是一个实用程序 - 它位于角落并定期更新两个不同的数据库。

这是一个使用 Spring Application Context 构建的小型独立应用程序。上下文中配置了两个 Hibernate Session Factories，依次使用 Spring 中配置的 Commons DBCP 数据源。

目前没有事务管理，但我想补充一些。对一个数据库的更新取决于对另一个数据库的成功更新。

该应用程序不位于 Java EE 容器中 - 它由从 shell 脚本调用的静态启动器类引导。启动器类实例化应用程序上下文，然后调用其中一个 bean 上的方法。

围绕数据库更新进行事务处理的“最佳”方式是什么？

我将把“最佳”的定义留给您，但我认为它应该是“易于设置”、“易于配置”、“便宜”和“易于打包和重新分发”的一些功能。自然开源软件会很好。

有没有办法在 Spring 应用程序中静态/全局请求 ApplicationContext 的副本？

假设主类启动并初始化应用程序上下文，它是否需要通过调用堆栈将其传递给任何需要它的类，或者有没有办法让一个类请求先前创建的上下文？（我认为必须是单身人士？）

我了解依赖注入本身的好处。让我们以 Spring 为例。我也了解其他 Spring 特性的好处，如 AOP、不同类型的助手等。我只是想知道，XML 配置有什么好处，例如：

与普通的旧 java 代码相比，例如：

这更容易调试，编译时间检查，任何只知道java的人都可以理解。那么依赖注入框架的主要目的是什么？（或一段显示其好处的代码。）

更新：
如果

如果有多个，IoC 框架如何猜测我要注入的 myService 的哪个实现？如果给定接口只有一个实现，并且我让 IoC 容器自动决定使用它，那么在出现第二个实现后它将被破坏。而且，如果故意只有一种可能的接口实现，那么您不需要注入它。

看到 IoC 的一小部分配置显示它的好处会非常有趣。我使用 Spring 已经有一段时间了，我无法提供这样的例子。我可以展示单行代码来展示我使用的 hibernate、dwr 和其他框架的好处。

更新 2：
我意识到可以在不重新编译的情况下更改 IoC 配置。这真的是个好主意吗？我可以理解何时有人想要更改数据库凭据而不重新编译 - 他可能不是开发人员。在您的实践中，开发人员以外的其他人多久更改一次 IoC 配置？我认为对于开发人员而言，无需重新编译该特定类而不是更改配置。对于非开发人员，您可能希望让他的生活更轻松并提供一些更简单的配置文件。

更新 3：

接口及其具体实现之间映射的外部配置

让它外接有什么好处？您不必将所有代码都放在外部，虽然您绝对可以 - 只需将其放在 ClassName.java.txt 文件中，即时手动读取和编译 - 哇，您避免了重新编译。为什么要避免编译？！

您可以节省编码时间，因为您以声明方式提供映射，而不是在程序代码中

我知道有时声明性方法可以节省时间。例如，我只声明一次 bean 属性和 DB 列之间的映射，hibernate 在加载、保存、构建基于 HSQL 的 SQL 等时使用此映射。这就是声明性方法的工作原理。在 Spring 的情况下（在我的示例中），声明有更多的行并且与相应的代码具有相同的表现力。如果有这样的声明比代码短的例子 - 我想看看。

控制反转原则允许简单的单元测试，因为您可以用假的实现替换真实的实现（比如用内存中的替换 SQL 数据库）

我确实理解控制反转的好处（我更喜欢将这里讨论的设计模式称为依赖注入，因为 IoC 更通用 - 有多种控制，我们只反转其中一种 - 初始化控制）。我在问为什么有人需要编程语言以外的东西。我绝对可以使用代码用假的实现替换真实的实现。这段代码将表达与配置相同的内容——它只会用假值初始化字段。

我确实了解 DI 的好处。我不明白与配置相同的代码相比，外部 XML 配置有什么好处。我认为不应该避免编译——我每天都在编译，而且我还活着。我认为 DI 的配置是声明性方法的坏例子。如果声明一次并且以不同的方式多次使用，则声明可能很有用 - 例如 hibernate cfg，其中 bean 属性和 DB 列之间的映射用于保存、加载、构建搜索查询等。Spring DI 配置可以很容易地转换为配置代码，就像在这个问题的开头一样，不能吗？而且它仅用于 bean 初始化，不是吗？这意味着声明性方法不会在此处添加任何内容，是吗？

当我声明hibernate映射时，我只是给hibernate一些信息，它基于它工作——我不告诉它做什么。在春天的情况下，我的声明告诉春天到底要做什么——那么为什么要声明它，为什么不直接去做呢？

最后更新：
伙计们，很多答案都在告诉我有关依赖注入的信息，我知道这很好。问题是关于 DI 配置的目的而不是初始化代码 - 我倾向于认为初始化代码更短更清晰。到目前为止，我对我的问题的唯一答案是，当配置更改时，它可以避免重新编译。我想我应该发布另一个问题，因为这对我来说是一个很大的秘密，为什么在这种情况下应该避免编译。

当我编写解析命令行参数的 Spring 命令行应用程序时，如何将它们传递给 Spring？我是否想让我的 main() 结构化，以便它首先解析命令行参数然后初始化 Spring？即便如此，它如何将保存已解析参数的对象传递给 Spring？

索引上有一个 UNIQUE 数据库约束，它不允许多个记录具有相同的列。

有一段代码，由 Hibernate (v2.1.8) 管理，执行两次 DAO
getHibernateTemplate().save( theObject )
调用，结果将两条记录输入到上面提到的表中。

如果此代码在没有事务的情况下执行，则会产生 INSERT、UPDATE，然后是另一个 INSERT 和另一个 UPDATE SQL 语句，并且工作正常。显然，顺序是先插入包含 DB NULL 的记录，然后用适当的数据更新它。

如果此代码在包装在单个 Spring 事务中的 Spring (v2.0.5) 下执行，则会导致两个 INSERTS，然后由于上述 UNIQUE 约束而立即出现异常。

由于与 ANSI SQL 不兼容，此问题仅在MS SQL上表现出来。它在 MySQL 和 Oracle 上运行良好。不幸的是，我们的解决方案是跨平台的，必须支持所有数据库。

拥有这些技术堆栈，对于给定问题，您首选的解决方法是什么？

您的应用程序的哪些部分没有编码？我认为最明显的例子之一就是数据库凭证——硬编码被认为是不好的。在大多数情况下，很容易决定是否要外部化或编码。对我来说，规则很简单。如果出现以下情况，应将应用程序的某些部分外部化：

1. 它可以并且应该由非开发人员更改，但不经常包含在 UI 中定义的应用程序设置中（数据库凭据、服务 URL 等）
2. 它不需要编程语言并且看起来不自然被编码（本地化）

你有什么要补充的吗？

这与这个关于 spring cfg的问题有点相关。Spring 配置对我来说似乎不太明显，因为在我的实践中，除了开发人员之外，任何人都不会修改它。而外化的道路可以带你走很远，到整个项目都被“配置”，而不是编码——那么在哪里停下来呢？

因此，请根据您的经验在此处发布一些示例，当您从配置而不是编码的东西中受益时 - 比如 spring 中的依赖注入配置等。如果您使用 spring - 在不重新编译的情况下多久更改一次配置？

我想在春天做以下事情：

我认为这将访问 bean1 的 getFoo() 方法并调用 bean2 的 setPropName() 方法，但这似乎不起作用。

我正在尝试在 Eclipse 中设置一个多模块 SpringMVC appfuse 应用程序，但在 Eclipse 中导入项目后，我似乎在 Eclipse 中遇到了很多错误。谁能帮助我一步一步的指导，显示在 Eclipse 中设置此类应用程序的理想方法？

在我刚刚完成的项目中，我正在努力让分布式事务正常工作。

我们使用 JBoss 的 Arjuna 事务管理器和 Spring 的声明性事务边界来实现这一点。

我们的请求序列如下所示：

这意味着我们有一个 WAR 服务于我们的安全 servlet 和一个 EAR 服务于我们的 SLSB。

我们的 SLSB 有一个静态初始化块来引导我们的 Spring 应用程序上下文。

我不喜欢技术的混合，但我喜欢表示层和业务层的分离，它们可以驻留在不同的物理位置。

我很想知道其他人在使用 Spring 时建议将层分开吗？