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，則準備將整體組件最終分成較小的項目可能是個好主意。

想象一下，您將需要從整體項目中提取微服務。 或將整個項目拆分為微服務。 我希望每個人都理解，沒有理智的微服務架構被架構層分開。 使用基于特征的分離。 那么哪種項目結構將更容易劃分為微服務？ 一個，在哪里任何公共類都可以使用任何包中的任何其他公共類（逐層打包）？ 還是一個，分成軟件包專用存儲桶（按功能分組）？ 我相信答案是顯而易見的。

結論

按功能打包是一種簡單但非常強大的去耦機制 。 因此，下一次某位癡迷的開發人員將作為解耦機制逐層捍衛項目結構時，請糾正她/他的誤解。 我相信恐龍般的性格是當今仍然存在逐層包裝的唯一原因。

翻譯自: https://www.javacodegeeks.com/2018/02/package-layer-spring-project-obsolete.html

spring api層打包

總結

以上是生活随笔為你收集整理的spring api层打包_Spring项目的按层打包已过时的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。