33

也許這很明顯。我是java新手(半年工作),我和我的同事討論過。我有麻煩根據他們的職責命名我的班級。爲此,我的班級獲得了他們不應該承擔的責任。什麼時候打電話給我的班級管理員,經理或服務?

你能幫我嗎?

BTW:我在一個項目中,我必須使用由服務類持久性一個層工作電流。我已經將我的軟件包分爲模型,服務和持久性。

回答

41

有一定的圖案,並且這些術語後面的準則,這是在我通常將它基於:

控制器是基於Model-View-Controller design圖案以及用於實現基於控制器的功能的類應當明確地使用在這個設計模式上。例如。如果您使用的是Spring MVC,並且您從其中一個Controller類擴展而來。

服務有點不太具體,但我建議從"Patterns of Enterprise Application Architecture基礎上Service Layer模式的實施。」基本上,其中控制器更特定平臺(如運輸通過基於HTTP和超文本,通常的HTML網頁的渲染控制器)服務不應該知道誰在使用它和如何,你只是提供一個統一的界面,可以通過例如一個web控制器輪流使用

管理器好...管理的東西。連接,應用程序上下文,會話;通常作爲整個應用程序中的組件可以與之通話的中心位置

0

我不知道如果我命名的一類經理,所以我會離開它。

對我來說控制器東西控股或決定應該在哪裏的東西(信號,消息,..)走。

服務是一個接口(和該接口的實現)提供一些功能,通常在系統或子系統的邊界。儘可能隱藏實施細節。

9

有關命名約定,請參閱官方convention

經理 - 正如其名稱所暗示其管理在你的代碼一樣EntityManager的東西,它管理實體,事務管理器 - 它負責管理事務。所以你可以有一種叫做SecurityManager的管理器來管理哪個Algo用於加密e.t.c

控制器 - 名字說得很多,控制如何做什麼或者如何完成。對於例如ActionController - 處理接收用戶操作事件的操作

服務 - 考慮它類似於postalService,由某人在一般筆記上執行的任務,您可以使用它。

包裝代碼需要大量的思考,你的應用程序包裝應始終對齊到它所迎合的商業模式。

隨着商業模式,你需要考慮如果功能是非常在應用程序的核心,所以你會把它移動到核心,說如果功能是與其他應用程序交談,你想移動它整合等。

+0

公約,應mentionned的是堅持你的業務的約定,而不是Sun的更好。 Sun的指南無疑是一個很好的起點,但最終,你cowerkers會維護你的代碼(和你最終會保持他們的),所以您應該按照公司的慣例(如果有的話那就是..)。 – Laf

+0

同意了,但肯定或多或少貴公司的編碼標準樣將遵循陽光;) – mprabhat

+0

我希望你說的是真的。)但我想,我們可以有一些有趣的挖掘最瘋狂的編碼標準在那裏。 – Laf

10

要添加到已經給出很好的答案,如果你發現你有一個艱難的時間爲你的類找到一個合適的名字,那麼也許如果你的班級有一個以上的責任,你應該調查。如果是這樣的話,那麼你一定要重構代碼,以責任隔離到單獨的類。

相關問題