java spring项目实践,第一个Java EE Spring项目的“最佳实践”是什么？

小提示 – 我发现有必要基于应用程序的关注模块化和清晰地标记我的Spring xml上下文文件。这是一个我曾经使用的网络应用程序的例子：

> 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 beans添加到controllers.xml文件，或者创建一个security.xml上下文文件？您对不同的部署/环境有不同的安全要求吗？

集成测试

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

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

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

适用于Spring IDE的豆图

拥有大量专注和命名的上下文文件，可以轻松创建自定义BeansConfigSets，以使用Spring IDE的Beans Graph可视化应用程序层。我之前已经使用过这个方法，让新的团队成员对应用程序的组织进行了高级概述。