java - Spring MVC アプリケーションのサービス層に使用する命名規則は何ですか?

Question

春のアプリケーションでサービス層の適切な命名規則を考え出すことに固執しています。サービス層の各クラスについて、最初に実装するインターフェイスを記述し、次に実際のクラスを記述します。たとえば、次のインターフェイスがあります。

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

そして、実装クラス...

ここで私を悩ませているのは、UserAccountManager が実装クラスの適切な名前であるため、SimpleUserAccountManager や UserAccountDbManager のようなばかげた名前を付けざるを得ないことです。これまでに使用した規則にはどのようなものがありますか? 実装クラスを別のパッケージに入れて、インターフェースと同じ名前を付けるのは良い考えですか? また、Service で終わる名前よりも Manager で終わる名前を使用することについてどう思いますか?

score 63 · Accepted Answer

使用するものは次のとおりです。

XxxDAO (データアクセスオブジェクト) - EntityManager 、 JDBC DataSource 、ファイルシステムなどとの直接対話を担当します。SQL や JPA-QL などの永続化ロジックのみを含める必要がありますが、ビジネスロジックは含めない (またはできるだけ少なくする) 必要があります。マネージャーからのみアクセスする必要があります。
XxxManager - ビジネスレベルでエンティティを管理し、通常は CRUD 操作を実行しますが、必要なビジネスロジックを追加します。
XxxService - ビジネスロジックが存在するレイヤー。単純なオブジェクト (文字列、int など) でできるだけ「話す」必要があります。
XxxController - UI インタラクションレイヤー。サービスのみと話す必要があります。
XxxUtilities/XxxUtils - ヘルパーステートレスメソッド。システム内のどのサービスにも依存してはなりません。このような依存性が必要な場合は、ユーティリティクラスをサービスに変換するか、サービスの結果をパラメーターとして追加します。

実装には、インターフェースと区別するために Impl サフィックス (XxxServiceImpl) を追加します。複数の実装がある場合、または追加情報を追加する場合は、それをプレフィックスとして追加します (JdbcXxxDaoImpl、GoogleMapsGeocodingServiceImpl など)。このようにクラス名は少し長くなりますが、非常に説明的で自己文書化されています。

score 19 · Accepted Answer

Spring自体がインターフェースに総称名を付け、実装の詳細に基づいてクラスに名前を付けます。これは頭に浮かぶ一例です：

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

SimpleUserAccountManagerやUserAccountDbManagerのような名前は、マネージャー/サービスの実装に関する情報を伝えるため、愚かではないと思います。

私が愚かだと思うのは、実装クラスに「Impl」接尾辞を追加する一般的な規則です。

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

しかし、これを好む人もいます。

score 10 · Accepted Answer

あなたが与える例では、HibernateUserAccountManager、JPAUserAccountManager、JDBCUserAccountManagerなど、またはおそらくUserAccountManagerDAOなど、クラスが操作を実行する方法を反映する実装名を使用します。

score 8 · Accepted Answer

クラス名が Manager で終わるか Service で終わるかは、明らかに重要ではありません。一般的に重要なことは、名前がモデル化されているものを正確に伝えることです。それが問題の核心です。「サービス」または「マネージャー」は、ソフトウェアオブジェクトでモデル化しようとする現実世界のオブジェクトではありません。むしろ、それらは、モデル化する必要がある/モデル化したいオブジェクトの責任に単に適合しないことを行う一連のメソッドを収集する場所です。

個人的には「サービス」の方が好きですが、それは「マネージャー」が実際にモデル化できるもののように見えるからです。つまり、「-manager」オブジェクトが表す実世界のマネージャーが存在する可能性があるからです。しかし、この点は完全に学術的なものであり、実際には何の違いもないことをすぐに認めます。

通常、本当に重要なことは、こうした細かい点よりもはるかに基本的なことです。つまり、開発に携わるすべての人がよく理解できるモデルを用意することです。私の経験が通用するものである場合、それはめったにありません。したがって、「マネージャー」または「サービス」のどちらが適切な比喩であるかを尋ねる人へのヒントは、次のとおりです。

score 3 · Accepted Answer

ServiceとManagerの命名サフィックスは、純粋に好みだと思います。「サービス」が混乱を招くのは、サービス層の上に Web サービスが存在する場合だけです。一部のプロジェクトでは、単に Web サービスクラスをブローカーと呼んでいました。ブローカーが行うのは、Web サービス呼び出しをサービス層への呼び出しに変換または仲介することだけだったからです。

実装の末尾に「Impl」を付けるのは良い方法ではないという kgiannakakis の意見に同意します。また、これを行わないように言及しているコーディングのベストプラクティスにも出くわしました。抽象化後にインターフェイスに名前を付けることが、一般的に受け入れられているベストプラクティスです。kgiannakakis が提案したように、インターフェースの後にその目的またはタイプの指標を付けて実装クラスを命名することは、一般的に受け入れられているアプローチのようです。

Web サービスベースの DAO と ORM ベースの DAO がある場合は、パッケージとクラス名の両方を使用して、実装クラスをそれらのインターフェイスや相互から区別します。実装を異なるパッケージに入れることは、パッケージに含まれるクラスの数、それらの実装の違い、およびどれだけ分割したいかによると思います。

score 2 · Accepted Answer

インターフェイスに IUserAccountManager という名前を付けて (この規則は、たとえば Eclipse RCP で使用されます)、デフォルトの実装に UserAccountManager を使用することもできます。

score 2 · Accepted Answer

私にとって、サービスクラスはユースケースの実装に関するものです。そのため、サービスがどのようなユーザーに代わって動作しているかに応じて名前を付けています。たとえば、顧客、注文フルフィルメント担当者、データ入力担当者、管理者など、さまざまなロールを持つアプリケーションがある場合、CustomerService、OrderFulfillmentService、DataEntryService、および AdminService を使用する可能性があります。フェッチまたはいじるデータの種類に応じてサービスに名前を付けるのはアンチパターンだと思います。したがって、UserAccount 操作が管理者のドメインになると推測すると、おそらく「AdminService」と呼ぶことになります。

score 1 · Accepted Answer

これらが REST サービス用であると仮定すると、URI 命名規則は、基盤となる実装サービスの名前よりも重要であると思います。後者はクライアントにはほとんど見えないためです。もちろん、内部的に一貫した命名が必要ですが、それほど重要ではありません。

私たちが使用したいくつかの REST ガイドライン: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (私のブログ)

java - Spring MVC アプリケーションのサービス層に使用する命名規則は何ですか?

9 に答える 9

Related

Reference