spring api层打包_Spring项目的按层打包已过时

spring api层打包

我认为Spring应用程序不应该以逐层方法构造。在我看来，按功能打包更有意义。

首先，让我简要描述每种方法。

“按层打包”（在非Java世界中为“按类型折叠”）

该项目结构根据源代码文件所属的体系结构层将其分为包/目录：

.
└── net└── lkrnac└── blog├── Application.java├── persistence│   ├── ProjectRepository.java│   └── UserRepository.java├── dto│   ├── ProjectDto.java│   └── UserDto.java├── model│   ├── Project.java│   └── User.java├── service│   ├── ProjectService.java│   └── UserService.java└── web├── ProjectController.java└── UserController.java

“按功能打包”（非Java世界中的“按功能折叠”）

另一方面，此方法将属于系统内某些功能的文件组合在一起：

.
└── net└── lkrnac└── blog├── Application.java├── project│   ├── ProjectController.java│   ├── ProjectDto.java│   ├── Project.java│   ├── ProjectRepository.java│   └── ProjectService.java└── user├── UserController.java├── UserDto.java├── User.java├── UserRepository.java└── UserService.java

发展趋势

这个话题使我很久了。当我用谷歌搜索“按层打包”还是“按功能打包”还是“按类型打包”还是“按功能打包”时，“按功能”结构的支持者似乎越来越多。我也在这个营地。

但是不仅应用程序开发人员是它的支持者。 Angular（最著名的Single Page Application框架之一）正在其样式指南中推广这种文件夹结构。

Spring项目结构

由于有很多关于每种方法的利弊的文章，我将重点介绍对Spring项目的影响。

放下Spring CRUD应用程序的传统结构（如果您的后端应用程序未使用Spring Data REST）分为三层：Web /服务/持久性。我从事的大多数Java / Spring项目都遵循这种结构。

耦合

逐层封装很可能起源于上个世纪，在那里分层结构被用作去耦机制。实际上，当我挑战逐层结构时，“解耦”通常是答案。我不同意。对我来说，逐层封装是导致紧密耦合的主要原因之一。

在逐层结构化项目中为类编写签名时，第一个关键字是什么？我敢打赌这是公开的。 公共访问修饰符是否有助于解耦？ 我想没有人会回答 是这个问题。

为什么开发人员到处使用公共访问修饰符？正是因为该项目是以分层方式构造的。存储库类需要是公共的，因为它需要从服务包中进行访问，而服务也必须是公共的，因为需要从Web包中进行访问。当一切都公开时，很难维持纪律，不会导致大的泥潭。

使用按功能打包时，私有UserRepository包私有（这意味着未指定访问修饰符）不能由UserService以外的其他服务使用，因为它们位于同一包中。而且，如果我们决定仅UserController应该使用UserService，则将其打包为私有，因为它们共享同一包。在这样的项目结构中，大多数类都是包私有的。因此，开发人员应该有充分的理由公开课堂。

缩放比例

如果项目在Web /服务/持久层中开始具有10多个类，会发生什么情况？开发人员倾向于将类分组为子包。但是他们如何对它们进行分类？根据我的经验，它主要基于功能。因此，我们经常可以在较大的项目中找到这样的结构：

.
└── net└── lkrnac└── blog├── Application.java├── dao│   ├── ...other repositories...│   ├── ProjectRepository.java│   └── user│       ├── UserRepository.java│       └── UserRoleRepository.java├── dto│   ├── ...other DTOs...│   ├── ProjectDto.java│   └── user│       ├── UserDto.java│       └── UserRoleDto.java├── model│   ├── ...other models...│   ├── Project.java│   └── user│       ├── User.java│       └── UserRole.java├── service│   ├── ...other services...│   ├── ProjectService.java│   └── user│       ├── UserRoleService.java│       └── UserService.java└── web├── ...other controllers...├── ProjectController.java└── user├── UserController.java└── UserRoleController.java

这不是明显的疯狂吗？

未来的证明

正如一群聪明人所建议的那样，用微服务体系结构启动绿色领域项目可能不是一个好主意。我同意。因此，如果您的应用程序增长Swift，则准备将整体组件最终分成较小的项目可能是个好主意。

想象一下，您将需要从整体项目中提取微服务。或将整个项目拆分为微服务。我希望每个人都理解，没有理智的微服务架构被架构层分开。使用基于特征的分离。那么哪种项目结构将更容易划分为微服务？一个，在哪里任何公共类都可以使用任何包中的任何其他公共类（逐层打包）？还是一个，分成软件包专用存储桶（按功能分组）？我相信答案是显而易见的。