溧阳企业网站建设,中国制造网官网入口,网站群建设原则,网络规划设计师教程第三版云盘下载我认为Spring应用程序不应该以逐层方法构建。 在我看来#xff0c;按功能打包更有意义。 首先#xff0c;让我简要描述每种方法。 “按层打包”#xff08;在非Java世界中为“按类型折叠”#xff09; 该项目结构根据源代码文件所属的体系结构层将它们分为包/目录#x… 我认为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最著名的单页应用程序框架之一正在其样式指南中推广此类文件夹结构。 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增长则准备好整体以最终分成较小的项目可能是个好主意。 想象一下您将需要从整体项目中提取微服务。 或将整个项目拆分为微服务。 我希望每个人都明白没有理智的微服务架构被架构层分开。 使用基于特征的分离。 那么哪种项目结构将更容易划分为微服务 一个其中任何公共类都可以使用任何包中的任何其他公共类逐层打包 还是一个分成多个包专用存储桶按功能打包 我相信答案是显而易见的。 结论 按功能打包是一种简单但非常强大的去耦机制 。 因此下一次某位痴迷的开发人员将作为解耦机制逐层捍卫项目结构时请纠正她/他的误解。 我认为恐龙化是当今仍然存在逐层包装的唯一原因。 翻译自: https://www.javacodegeeks.com/2018/02/package-layer-spring-project-obsolete.html
