对于第一个 Java EE Spring 项目，您的“最佳实践”是啥？ [关闭]

Posted 2023-02-26

【中文标题】对于第一个 Java EE Spring 项目，您的“最佳实践”是啥？ [关闭]

【英文标题】：What's your "best practice" for the first Java EE Spring project? [closed]对于第一个 Java EE Spring 项目，您的“最佳实践”是什么？ [关闭]

【发布时间】：2010-09-05 17:35:10

【问题描述】：

我目前正在尝试使用 Spring 框架进行 Java EE 开发。由于我是 Spring 新手，很难想象一个好的运行项目应该如何开始。

您有任何最佳实践、提示或主要不要作为初学者吗？您是如何开始使用 Spring 的——大型项目或类似教程的小型应用程序？你马上用了哪一种技术：AOP、复杂的Hibernate……

【问题讨论】：

是否必须同时使用两者？如果您对两者都不熟悉，一次处理一个会更容易（不清楚 Java EE 对您来说是否是新手）。

【参考方案1】：

小提示 - 我发现根据应用程序关注模块化和清晰地标记我的 Spring xml 上下文文件很有帮助。以下是我开发的 Web 应用的示例：

MyProject / src / main / resources / spring / datasource.xml - 我的单一数据源 bean。 persistence.xml - 我的 DAO/存储库。取决于datasource.xml bean。 services.xml - 服务层实现。这些通常是我使用 AOP 应用事务性的 bean。取决于persistence.xml bean。 controllers.xml - 我的 Spring MVC 控制器。取决于services.xml bean。 views.xml - 我的视图实现。

这个列表既不完美也不详尽，但我希望它能说明这一点。选择最适合您的命名策略和粒度。

根据我的（有限的）经验，我发现这种方法具有以下好处：

架构更清晰

清晰命名的上下文文件为那些不熟悉您的项目结构的人提供了一个合理的 开始寻找 bean 定义的地方。可以更轻松地检测循环/不需要的依赖项。

帮助域设计

如果您想添加一个 bean 定义，但它不适合您的任何上下文文件，也许是出现了一个新概念或问题？例子：

假设您希望使用 AOP 使您的服务层事务化。您是将这些 bean 定义添加到 services.xml，还是将它们放在自己的 transactionPolicy.xml 中？与您的团队讨论。您的交易政策应该是可插拔的吗？ 将 Acegi/Spring Security bean 添加到您的 controllers.xml 文件中，还是创建一个 security.xml 上下文文件？对于不同的部署/环境，您是否有不同的安全要求？

集成测试

您可以连接应用程序的一个子集以进行集成测试（例如：给定上述文件，要测试您只需要创建 datasource.xml 和 persistence.xml bean 的数据库）。

具体来说，您可以这样注释集成测试类：

@ContextConfiguration(locations =  "/spring/datasource.xml" , "/spring/persistence.xml" )

与 Spring IDE 的 Beans Graph 配合良好

拥有大量集中且命名良好的上下文文件可以轻松创建自定义 BeansConfigSet 以使用 Spring IDE 的 Beans Graph 可视化应用程序的层。我以前用它来为新团队成员提供我们应用程序组织的高级概述。

【参考方案2】：

首先关注 Spring 的核心：依赖注入。一旦你了解了可以使用 DI 的所有方式，然后开始考虑更有趣的部分，如 AOP、Remoting、JDBC 模板等。所以我最好的建议是让你对 Spring 的使用从核心发展出来。

最佳实践？如果您使用标准 XML 配置，请管理单个文件的大小并明智地对其进行注释。您可能认为您和其他人会完全理解您的 bean 定义，但实际上它们比简单的旧 java 代码更难返回。

祝你好运！

【参考方案3】：

首先，Spring 是关于模块化的，如果一个人专注于编写做一件事并且做得很好的小组件，那么它的效果最好。

如果您遵循一般最佳做法，例如：

定义接口而不是抽象类 使类型不可变 尽量减少单个类的依赖关系。 每个班级都应该做一件事并把它做好。大型单体类很糟糕，它们很难测试也很难使用。

如果您的组件很小并且遵循上面的教条，那么它们应该很容易连接并与其他东西一起使用。以上几点自然也适用于 Spring 框架本身。

PS

不要听上面的观点，他们在谈论如何做任何事情。学习如何思考比如何做事更重要。人类可以思考，重复某事并不聪明，思考才是。

【参考方案4】：

我其实很喜欢 Spring。它在普通的 J2EE Java Beans 中是一股清新的空气。

我建议实现 Spring 提供的示例：

http://static.springframework.org/docs/Spring-MVC-step-by-step/

另外，我决定全力以赴，将 Hibernate 添加到我的 Spring 应用程序中；)，因为 Spring 为 Hibernate 提供了出色的支持... :)

我确实有一个 DON'T 但是，我学到了很难的方法（生产中的产品）......如果你只实现 Controller 接口，并返回一个 ModelAndView 对象，其中包含接口提供的一些数据，Spring 会garbadge 收集这些资源，以尝试缓存这些数据。所以要小心将大数据放在那些 ModelAndView 对象中，因为只要服务器在查看该页面后立即运行，它们就会占用您的服务器内存......

【讨论】：

超链接中的好书

【参考方案5】：

从这里开始 - 实际上我认为这是我读过的最好的软件开发书籍之一。Expert Spring MVC And Web Flow

了解 MVC 类的基于注解的新配置。这是 Spring 2.5 的一部分。使用基于注释的类将使编写单元测试变得容易得多。能够减少 XML 的数量也是一件好事。

哦，是的，单元测试——如果你使用的是 Spring，你最好是单元测试。 :) 为所有 Web 和服务层类编写单元测试。

阅读领域驱动设计。您可以在 Spring 应用程序的所有级别使用域对象类这一事实意味着您将拥有一个非常强大的域模型。充分利用它。

但是，当使用域对象类来填充表单时，您需要注意最近围绕 Spring 框架的安全问题。 A discussion on the Server Side 揭示了关闭 cmets 孔的方法。

【参考方案6】：

开始的一个好方法是专注于“Springframework”。 Spring 产品组合已经发展成为围绕企业软件各个方面的大量项目。一开始就坚持核心，并尝试掌握概念。 Download 最新的二进制文件并在您熟悉核心后查看 Spring 的宠物诊所示例。它很好地概述了 SpringSource 必须提供的各种项目。

虽然文档很好，I'd recommend a book在你掌握了核心的概念之后。我发现文档存在问题，它不够深入，无法为您提供所需的所有详细信息。

【参考方案7】：

“...您立即使用了哪种技术：AOP，复杂的 Hibernate...” - 我想说一个更好的问题是问人们没有立即使用什么。我会将您引用的示例添加到该列表中。

Spring MVC 和 JDBC 模板是我的入门建议。仅凭这些，您就可以走很长的路。

我的建议是忠实地遵循 Spring 架构建议。使用他们的分层想法。确保您的 Web 图层与其他图层完全可分离。您可以通过让 Web 层仅通过服务层与后端交互来做到这一点。

如果您想重用该服务层，一个好的建议是使用 Spring“契约优先”Web 服务来公开它。如果您从来回传递的 XML 消息开始，您的客户端和服务器可以完全解耦。

具有最佳 Spring 支持的 IDE 是 IntelliJ。花几块钱是值得的。

【参考方案8】：

虽然我使用 spring 已经有好几年了，而且我不能说我是它的粉丝，但我知道 App Fuse 工具 (https://java.net/projects/appfuse/) 有助于帮助人们引导生成所有您需要开始的工件。

【参考方案9】：

Spring 也非常关注单元测试，因此也关注类的可测试性。这基本上意味着考虑模块化、关注点分离、通过接口引用类等。

【参考方案10】：

如果您只是想尝试一下，看看您是否喜欢它，我建议您从 DAO 层开始，使用 Spring 的 JDBC 和/或 Hibernate 支持。这将使您接触到许多核心概念，但这样做的方式很容易与您的应用程序的其余部分隔离开来。这是我遵循的路线，在开始使用 Spring 构建完整的应用程序之前，这是一个很好的热身。

【参考方案11】：

随着 Spring 2.5 和 3.0 的发布，我认为现在可以利用的最重要的最佳实践之一是 Spring 注释。控制器、服务和存储库的注释可以为您节省大量时间，让您专注于应用程序的业务逻辑，并且可能让您的所有对象都变成普通的旧 Java 对象 (POJO)。