您在Spring MVC應用程序中對服務層使用了什麼命名約定？

Question

我堅持，首先要弄清楚在彈簧應用服務層良好的命名約定。對於服務層中的每個類，我首先編寫它應該實現的接口，然後編寫實際的類。因此，例如，我有以下接口：

public interface UserAccountManager{ 
    public void registerUser(UserAccount newUserAccount); 
    public void resetPassword(UserAccount userAccount); 
... 
} 

然後實現類...

什麼錯誤我在這裏是UserAccountManager是實現類的好名字，所以我被迫給它像SimpleUserAccountManager或UserAccountDbManager這樣一個愚蠢的名字。 到目前爲止您使用的一些約定是什麼？將實現類放在不同的包中並給它們與接口相同的名稱是一個好主意嗎？ 另外對於以Service結尾的名稱使用以Manager結尾的名稱，您有什麼想法？

Answer 1

Spring本身提供了接口的通用名稱，然後名稱基礎上，實施的細節的類。這件事是記住了一個例子：

interface: Controller 
abstract classes: AbstractController, AbstractCommandController, 
        SimpleFormController, MultiActionController 

我不認爲像SimpleUserAccountManager或UserAccountDbManager名字是愚蠢的，因爲它們傳達與經理/服務的實現的一些信息。

我感到愚蠢的是在實現類中添加「默認地將Impl」後綴的共同約定：

my/package/UserAccountManager 
my/package/impl/UserAccountManagerImpl 

有些人喜歡這個，雖然。

Answer 2

我覺得服務與經理命名後綴純粹是一種偏好。 「服務」唯一導致我們混淆的時機是我們也有Web服務位於服務層之上。在一些項目中，我們簡稱爲Web服務類經紀人爲他們所做的一切是服務於翻譯或經紀人的Web服務調用到我們的服務層的調用。

我與你的後面添加實現kgiannakakis同意「默認地將Impl」是不是一個好方法。我也遇到過提到不這樣做的編碼最佳實踐。在抽象之後命名界面是普遍接受的最佳實踐。按照kgiannakakis的建議，在接口之後命名實現類並指定其目的或類型似乎是普遍接受的方法。

當我們有基於Web服務的DAO和基於ORM的DAO，我們使用這兩個軟件包和類名從各自的接口和區分彼此的實現類。我認爲將這些實現放在不同的包中取決於你在包中有多少個類，它們實現的方式有多不同，以及你想要分割多少個東西。

Answer 3

爲了你放棄，我會用反映實現名稱如何類進行操作，像HibernateUserAccountManager，或JPAUserAccountManager，或JDBCUserAccountManager等，或者只是UserAccountManagerDAO的例子。

Answer 4

你也可以命名接口IUserAccountManager（此慣例在Eclipse RCP中使用，例如），然後使用UserAccountManager的默認實現。

Answer 5

下面是我們使用：

• XxxDAO（數據訪問對象） - 負責直接與EntityManager的，JDBC數據源，文件系統等交互應該只包含持久性邏輯，如SQL或JPA-QL，但不包括（或儘可能少的）業務邏輯。只能從管理員訪問。
• XxxManager - 在業務級別管理實體，通常執行CRUD操作，但添加了所需的業務邏輯。
• XxxService - 其中業務邏輯駐留的層。應儘可能簡單地用「說」字符串，整數等。
• XxxController - 的UI交互層。只應該與服務對話。
• XxxUtilities/XxxUtils - 輔助無狀態方法，不應該依賴系統中的任何服務。如果您需要這樣的依賴性，請將實用程序類轉換爲服務或將服務結果添加爲參數。

對於我們從界面添加默認地將Impl後綴（XxxServiceImpl），以不同的它，如果有幾個實現或我們要添加更多的信息，我們將其添加爲前綴（JdbcXxxDaoImpl，GoogleMapsGeocodingServiceImpl等實施）。這些類的名稱有點長，但它們非常具有描述性和自我記錄。

Answer 6

這顯然不是本身是重要的類名是否在管理器或服務結束。一般來說，重要的是名稱準確地傳達了正在建模的內容。這就是問題的癥結所在：「服務」或「經理」不是我們嘗試在軟件對象中建模的真實世界對象。相反，他們是我們收集大量方法的地方，這些方法不能滿足我們需要/想要建模的任何對象的責任。

我個人更喜歡「服務」，但僅僅是因爲「經理」似乎是一個可以真正模擬的東西，也就是說，我們的「管理者」對象所代表的可能是現實世界的管理者。但這一點完全是學術性的，我立即承認它沒有任何實際區別。

真正重要的是通常比這樣的細微之處更爲基本的：爲了有一個良好的全民參與的發展理解的典範。如果我的經驗是任何事情經過，情況很少。因此，對於那些詢問「經理人」還是「服務人員」是正確的比喻的人，我的建議是：翻轉硬幣，確保每個人都知道約定，並花時間思考和討論重要事項！

Answer 7

對我來說一個服務類是關於實現一個用例，所以我根據服務代表什麼樣的用戶來命名它。因此，如果我有一個具有不同角色的應用程序，例如Customers，Order Fullfillment people，Data entry people和Admins，那麼我可能有一個CustomerService，一個OrderFulfillmentService，一個DataEntryService和一個AdminService。我認爲，根據所獲取或者轉儲的數據類型命名服務是一種反模式。因此，猜測UserAccount操作將是管理員的域名，我可能稱之爲「AdminService」。

Answer 8

假設這些用於REST服務，我認爲您的URI命名約定比底層實現服務的名稱更重要，因爲後者對於客戶端來說基本上是不可見的。當然你想要內部一致的命名，但它並不重要。

休息指引我們使用：http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html（我的博客）

Answer 9

相關的管理人員和服務之間的區別： 我會說使用一層爲只要業務邏輯（服務層或經理層）儘可能。

一旦該層變得複雜（假設您使用了服務），您可以添加管理員負責委託給一個或另一個服務，但將業務邏輯保留在服務內部。

所以我會保持服務簡單，使用經理來管理服務，並保持業務邏輯內的服務。

我也同意避免Impl後綴的實現和避免I後綴的接口。作爲一個例子，命名接口「Controller」並命名實現「SimpleController」或「UserController」對我來說聽起來更好。