我認為Spring應(yīng)用程序不應(yīng)該以逐層方法構(gòu)建。 在我看來，按功能打包更有意義。

首先，讓我簡要描述每種方法。

“按層打包”（在非Java世界中為“按類型折疊”）

該項目結(jié)構(gòu)根據(jù)源代碼文件所屬的體系結(jié)構(gòu)層將它們分為包/目錄：

. └── 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世界中的“按功能折疊”）

另一方面，此方法將屬于系統(tǒng)內(nèi)某些功能的文件組合在一起：

. └── 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

發(fā)展趨勢

這個話題使我很久了。 當(dāng)我用谷歌搜索“按層打包”還是“按功能打包”還是“按類型打包”還是“按功能打包”時，“按功能”結(jié)構(gòu)的支持者似乎越來越多。 我也在這個營地。

但是不僅應(yīng)用程序開發(fā)人員是它的支持者。 Angular（最著名的單頁應(yīng)用程序框架之一）正在其樣式指南中推廣此類文件夾結(jié)構(gòu)。

Spring項目結(jié)構(gòu)

由于有很多關(guān)于每種方法的利弊的文章，我將重點介紹對Spring項目的影響。

放下Spring CRUD應(yīng)用程序的傳統(tǒng)結(jié)構(gòu)（如果您的后端應(yīng)用程序未使用Spring Data REST）分為三層：Web /服務(wù)/持久性。 我從事的大多數(shù)Java / Spring項目都遵循這種結(jié)構(gòu)。

耦合

逐層封裝很可能起源于上個世紀(jì)，在那里分層結(jié)構(gòu)被用作去耦機制。 實際上，當(dāng)我挑戰(zhàn)逐層結(jié)構(gòu)時，“去耦”通常是答案。 我不同意。 對我來說，逐層封裝是導(dǎo)致緊密耦合的主要原因之一。

在逐層結(jié)構(gòu)化項目中為類編寫簽名時，第一個關(guān)鍵字是什么？ 我敢打賭這是公開的。 公共訪問修飾符是否有助于解耦？ 我想沒有人會回答 是這個問題。

為什么開發(fā)人員到處使用公共訪問修飾符？ 正是因為該項目是以分層方式構(gòu)造的。 存儲庫類需要是公共的，因為它需要從服務(wù)包中進行訪問，而服務(wù)也必須是公共的，因為它需要從Web包中進行訪問。 當(dāng)一切都公開時，很難保持紀(jì)律，不會導(dǎo)致大的泥潭。

使用按功能打包時，私有UserRepository程序包（這意味著未指定訪問修飾符）不能由UserService以外的其他服務(wù)使用，因為它們在同一程序包中。 而且，如果我們決定僅UserController應(yīng)該使用UserService，則將其打包為私有，因為它們共享同一包。 在這樣的項目結(jié)構(gòu)中，大多數(shù)類都是包私有的。 因此，開發(fā)人員應(yīng)該有充分的理由公開課程。

縮放比例

如果項目在Web /服務(wù)/持久層中開始具有10多個類，會發(fā)生什么情況？ 開發(fā)人員傾向于將類分組為子包。 但是，他們?nèi)绾螌λ鼈冞M行分類？ 根據(jù)我的經(jīng)驗，它主要基于功能。 因此，我們經(jīng)常可以在較大的項目中找到這樣的結(jié)構(gòu)：

. └── 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

這不是明顯的瘋狂嗎？

未來的證明

正如一群聰明人所建議的那樣， 從微服務(wù)架構(gòu)開始綠色領(lǐng)域項目可能不是一個好主意 。 我同意。 因此，如果您的應(yīng)用程序Swift增長，則準(zhǔn)備好整體以最終分成較小的項目可能是個好主意。

想象一下，您將需要從整體項目中提取微服務(wù)。 或?qū)⒄麄€項目拆分為微服務(wù)。 我希望每個人都明白，沒有理智的微服務(wù)架構(gòu)被架構(gòu)層分開。 使用基于特征的分離。 那么哪種項目結(jié)構(gòu)將更容易劃分為微服務(wù)？ 一個，其中任何公共類都可以使用任何包中的任何其他公共類（逐層打包）？ 還是一個，分成多個包專用存儲桶（按功能打包）？ 我相信答案是顯而易見的。

結(jié)論

按功能打包是一種簡單但非常強大的去耦機制 。 因此，下一次某位癡迷的開發(fā)人員將作為解耦機制逐層捍衛(wèi)項目結(jié)構(gòu)時，請糾正她/他的誤解。 我認為恐龍化是當(dāng)今仍然存在逐層包裝的唯一原因。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。