web-dev-qa-db-ja.com

Spring MVCアプリケーションのサービス層にはどのような命名規則を使用していますか？

Springアプリケーションのサービス層の適切な命名規則を理解するのに行き詰まっています。サービスレイヤーの各クラスについて、まず実装する必要のあるインターフェイスを記述してから、実際のクラスを記述します。したがって、たとえば次のインターフェイスがあります。

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

そして実装クラス...

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

javaspringnaming-conventionsspring-mvc
42
Vasil

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

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

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

私がばかげているのは、実装クラスに「Impl」サフィックスを追加する一般的な規則です。

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

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

18
kgiannakakis

これが私たちが使うものです：

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

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

57
David Rabinowitz

あなたが与える例では、私はhowを反映する実装名を使用します。クラスはHibernateUserAccountManager、JPAUserAccountManager、JDBCUserAccountManagerなどの操作を実行するか、または単にUserAccountManagerDAOを実行します。

7
skaffman

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

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

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

4
The Dag

Service対Managerの接尾辞は、純粋に好みだと思います。 「サービス」が混乱を招くのは、サービスレイヤーの上にWebサービスが配置されているときだけです。一部のプロジェクトでは、Webサービスの呼び出しをサービス層の呼び出しに変換または仲介するためにWebサービスクラスを単にブローカーと呼んでいました。

実装に "Impl"を付けるのは良い方法ではないことをkgiannakakisが同意します。また、これを行わないことに言及しているコーディングのベストプラクティスに遭遇しました。抽象化後にインターフェースに名前を付けることは、一般的に受け入れられているベストプラクティスです。 kgiannakakisが示唆したように、インターフェースの後に目的またはタイプのインジケーターを付けて実装クラスに名前を付けることは、一般的に受け入れられているアプローチのようです。

WebサービスベースのDAOとORMベースのDAOがある場合は、パッケージとクラス名の両方を使用して、実装クラスとそれらのインターフェイスとを区別します。実装をさまざまなパッケージに配置することは、パッケージ内にあるクラスの数、それらがどのように実装されているか、そしてどれだけ分割したいかによって決まると思います。

3
DavidValeri

私にとってサービスクラスはユースケースの実装に関するものであるため、サービスがどのようなユーザーに代わって動作しているのかに応じて名前を付けています。したがって、Customers、Order Fullfillment担当者、Data entry担当者、Adminsなど、さまざまな役割を持つアプリケーションがある場合、CustomerService、OrderFulfillmentService、DataEntryService、およびAdminServiceがおそらくあります。フェッチまたはいじられるデータの種類に従ってサービスに名前を付けることは、アンチパターンだと思います。したがって、UserAccountの操作が管理者のドメインであると推測すると、おそらく "AdminService"と呼びます。

2
Nathan Hughes

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

2
Ilya Boyandin

マネージャーとサービスの違いに関連します。できる限り、ビジネスロジックに1つのレイヤー（サービスレイヤーORマネージャーレイヤー））を使用するとします。

その層が複雑になると（サービスを使用したと想定）、マネージャーを追加して、サービスに委任する責任がありますが、サービス内のビジネスロジックは維持できます。

そのため、サービスをシンプルに保ち、マネージャーを使用してサービスを管理し、ビジネスロジックをサービス内に保持します。

実装の場合はImplサフィックスを回避し、インターフェースの場合はIサフィックスを回避することにも同意します。例として、インターフェースに「Controller」という名前を付け、実装に「SimpleController」または「UserController」という名前を付けると、私にはわかりやすいでしょう。

1
Anghel Contiu

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

REST使用したガイドライン： http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html （私のブログ）

1
Robert Morschel