web-dev-qa-db-ja.com

サービスクラスとヘルパークラスの違い

Serviceクラスとユーティリティクラスまたはヘルパークラスの違いを知りたいのですが。基礎となるメソッドのみを含むクラスがdaoを呼び出すのはサービスですか?ヘルパークラスの使用はSRPに違反していませんか?

64
tintin

線は少しぼやけている可能性がありますが、私はこのように見ています:

  • Serviceクラス/インターフェースは、クライアントがアプリケーションのいくつかの機能と対話する方法を提供します。これは一般的にパブリックであり、ビジネス上の意味があります。たとえば、TicketingServiceインターフェイスを使用すると、buyTicketsellTicketなどを実行できます。

  • ヘルパークラスはクライアントから非表示になる傾向があり、ビジネスドメインの意味を持たない定型的な作業を提供するために内部的に使用されます。たとえば、特定のデータストアに保存するために日付をタイムスタンプに変換したいとします。この処理を実行するDateConvertorメソッドを備えたconvertDateToTimestampというユーティリティクラスがある場合があります。

サービスは単にDAOと密接に結びついているのではなく、永続性よりも広い用語/使用パターンです

ヘルパークラスは、その原則に従ってコーディングされていれば、SRPに違反しません。つまり、各メソッドは1つのことと1つのことをうまく行う必要があり、クラスは1つのタイプのユーティリティヘルプ(日付変換など)を実行し、それをうまく行う必要があります。

77
Martijn Verburg

科学的な定義ではありませんが、私の一般的な見方では、サービスクラスにはアプリケーション内にコンテキストがありますが、ヘルパーはより一般的で、どのアプリが支援しているかは気にしません。

27
Wyatt Barnett

私にとって、私は次のような Eric Evansのservice の定義に従います。

一般に、適切に設計されたシステムでは、ほとんどのクラス(ドメインモデル内)は、モデル内の特定のエンティティまたはエンティティセットを処理するという点で、明確な責任または機能を持っています。

つまり.

  • アカウント、アカウントファクトリ、アカウントリポジトリなど
  • 顧客、顧客工場、顧客リポジトリなど

特定のエンティティに属さない機能がある場合、適切な場所を見つけるのが難しい場合があります。つまり、AccountCustomerの両方を含むプロセスをカプセル化するものです。

つまり、ここでserviceの出番です。ドメインモデルにあるが、あるエンティティ/コンポーネントまたは別のエンティティ/コンポーネントには本来属さないコードを配置する場所です。

helperは一種の戦略クラスと考えています。私にとっては、さまざまなクラスで再利用する必要があるが、それを使用するクラスの階層内に抽象メソッドとして適切に配置できないコードを配置する場所です。個人的に私はhelperという用語を少しあいまいにしており、私のモデルには実際にはありません。それらは私が使用するライブラリに存在しますが。

17
JW01

サービスクラス: ビジネスロジックが含まれています。
ヘルパークラス: このクラスは、再利用可能なコンポーネントの1つです。

14
Dhiral Pandya

関連のない2つのプリンシパルを混同しています。サービスとヘルパークラスは接続されていません。特に「サービスクラス」という用語は誤解を招く可能性があります。クラスよりも抽象化のレベルが高い「サービス」を指していると思います。サービスの特徴は

「1つまたは複数の機能へのアクセスを可能にするメカニズム。アクセスは、規定のインターフェイスを使用して提供され、サービスの説明で指定された制約とポリシーに従って実行されます。」

この定義は、状況に応じて少し異なります。ただし、重要な点は、「サービス」という用語が抽象的なレベル、つまりアーキテクチャとドメインの知識のレベルにあるということです。 「ヘルパークラス」は、一般的な操作をカプセル化するクラスを参照する設計パターンです(ブロブクラスまたはゴッドクラスに進化する傾向があるため、アンチパターンです)(これは抽象化アプリケーション/ソリューションの知識)に接続されています。ヘルパークラスを含まないソフトウェアはほとんど存在しないという事実を知っていますが、それでも悪い習慣です。

7
ins0m

注意すべきことの1つは、DDDでの「サービス」の複数の定義です。

アプリケーションサービス:これらはアプリケーション層にあり、ドメインおよびデータ層と通信します。これらは、外部システム/ UIがDDDシステムと対話するためのインターフェースです。

ドメインサービス:これは、ドメインまたはアプリケーションレイヤーで使用でき、1つの特定のエンティティに適切に適合しないビジネスロジックを含みます。

インフラストラクチャサービス:ドメインが外部リソースと通信するために使用します。

ヘルパークラスには、複数のエンティティによって再利用されるコードやアルゴリズムが含まれる傾向があるため、DRYの原則に違反しない限り、エンティティに入ることができません。これらは、おそらくドメインサービスに最も近いものです。ソートは同じ目的(エンティティーからのビジネスロジックの外部化)を満たしますが、理由は異なります。

4
Paul T Davies