設計應用程序層 - 您最佳實踐是什麼？

Question

設計應用程序層不是微不足道的。在一天結束時，我們在每個項目中都編寫（大量）所謂的業務方法（有時稱爲服務方法，儘管它與公共API中的服務無關）執行一些業務邏輯的方法通常會執行一些數據庫/存儲操作（通過存儲層）。但是，設計/組織/命名你的應用程序方法並不是微不足道的，人們通常對項目應該如何設計應用程序類和方法有規定。我找了一套實用的設計應用層這樣的規則，所以這裏有一些問題：

1. 分組方法類：返回類型或？

   例如，更新用戶的方法屬於類，例如UserService。或者通過某些標準查找用戶的方法屬於同一個類。但是，當某種方法適用於多種類型時會發生什麼，例如registerUserForCompetition()？這應該在UserService或CompetitionService？方法findUserCompetition()的相同問題 - 你會在哪裏放？

   我經常看到一個規則，說這取決於方法的返回類型。在我們的示例中，如果方法返回User（或用戶等的集合），它應該屬於UserService。方法參數：簡單類型（原始類型，字符串...）或實體（例如User,Competition,Registration ...）？

   這個問題經常被問到，人們通常（統計:)選擇第一種方法，使用簡單的類型作爲服務參數。但是當一個這樣的方法在同一個資源上調用另一個方法時該怎麼辦？讓我舉個例子：registerUser(userId, competitionId)可能會在內部呼叫checkCompetition(competitionId)。兩種方法都從存儲中獲取Competition。顯然，這是兩次完成的，因爲我們已經有了Competition對象，所以我們可以使用它到checkCompetition。所以我們應該添加重載的方法，或者我們應該忽略這一點，並真正在緩存機制，以防止雙重抓取？

   另一方面，具有完整類型作爲參數不能是通用規則，因爲不需要全部信息的次數很多，並且沒有理由在您需要的時候獲取完整對象，而您已經可以有它。

2. 命名方法：如何詳細的方法名稱應該是？

   尤其適用於查找方法。如果我們已經例如：

   • findCompetition(userId, year)或
   • findCompetitionWithVenue(userId, year)（因爲每個Competition對象鏈接Venue）;或
   • findCompetitionForUserAndYear(userId, year)或
   • findCompetitionByUserIdAndYear(userId, year)或只是
   • findUserCompetitionForYear(userId, year)？

   當不同標準的數量增加時，很容易弄亂查找方法名稱，並且我經常看到像這樣的規則：find<return-type>By<names-of-parameters>或類似的規則。

3. 您是否有應用程序類的命名約定？

   你的班級名字以Service結尾嗎？您是否將經理與服務分開，其中經理處理實體和服務只接受簡單類型？你是否將所有業務類別歸入同一個包中，或者將它們與其他相關類（模型，控制器...）一起按功能分組？

請分享注重務實的經驗 - 這對我來說意味着新的開發者可以很容易地計算在哪裏可以找到商業方法，以及如何編寫新的，所以每個人都更富有成效。另外，如果您已經制定了規則，請分享您的團隊如何管理他們。

Answer 1

1. 按功能分組的服務。在同一個軟件包中也應該是控制器，模型等的一部分，還有更好的方法，然後是分層架構。嘗試DDD。它完美地隔離了功能，使其更易於查找和更改

2. 通常，將實體（模型）隱藏到客戶端並通過DTO和ValueObjects與控制器進行通信是很好的做法。以防萬一你想在未來改變你的模型

3. 它們必須對你的域有意義且一致。如果你的團隊說他們不清楚，不要擔心重構。我個人會用findCompetition(user, year)與非原始類型，因爲你可以使用方法重載，但然後在調用中，你必須使用常量或閱讀使能像findCompetition(forUserId(userId), forYear(year))明確告訴讀者你正在調用的版本。

4. 什麼是經理？這不代表任何意思。類似於助手，處理程序等。服務包含將DTO轉換爲實體的邏輯，並且邏輯不能推送到域/實體，因爲邏輯在許多實體上操作。如前所述，我通過功能對組件（不僅僅是服務）進行分組，因此我添加了'服務'後綴，因爲它幫助我快速找到特定軟件包中的邏輯（包含模型，控制器，服務，存儲庫等）