とアノテーションはSpringで互換的に使用できますか@Component、それとも表記デバイスとして機能する以外に特定の機能を提供しますか？@Repository@Service

言い換えれば、私はServiceクラスを持っていると私はからの注釈を変更した場合@Serviceに@Component、それはまだ同じように動作しますか、？

または、注釈はクラスの動作と機能にも影響しますか？

Springドキュメントから：

@Repository注釈は、（また、データアクセスオブジェクトまたはDAOとしても知られる）リポジトリの役割またはステレオタイプを満たす任意のクラスのマーカーです。このマーカーの使用例には、例外の翻訳で説明されているように、例外の自動翻訳があります。

春はさらにステレオタイプのアノテーションを提供します@Component、@Serviceと@Controller。@ComponentSpringで管理されるコンポーネントの一般的なステレオタイプです。@Repository、@Service、および@Controllerの特殊化されている@Component（それぞれ、持続性、サービス、およびプレゼンテーションの層）より具体的なユースケースのために。したがって、コンポーネントクラスにで注釈を付けることができますが、、、またはで@Component注釈を付けることにより@Repository、 クラスはツールによる処理やアスペクトとの関連付けにより適切に対応します。@Service@Controller

たとえば、これらのステレオタイプアノテーションは、ポイントカットの理想的なターゲットになります。@Repository、@Service、そして @Controllerまた春のフレームワークの将来のリリースで追加のセマンティクスを運ぶことができます。したがって、サービスレイヤーを使用する@Componentか@Service、サービスレイヤーに使用するかを選択している場合 @Serviceは、明らかにより良い選択です。同様に、前に述べたように、@Repositoryは永続化レイヤーでの自動例外変換のマーカーとして既にサポートされています。

┌──────────────┬─────────────────────────────────────────────────────┐
│ Annotation   │ Meaning                                             │
├──────────────┼─────────────────────────────────────────────────────┤
│  @Component  │ generic stereotype for any Spring-managed component │
│  @Repository │ stereotype for persistence layer                    │
│  @Service    │ stereotype for service layer                        │
│  @Controller │ stereotype for presentation layer (spring-mvc)      │
└──────────────┴─────────────────────────────────────────────────────┘

回答の多くはこれらの注釈の使用目的をすでに述べているので、ここではそれらの間のいくつかの小さな違いに焦点を当てます。

最初に類似点

もう一度強調する価値のある最初の点は、BeanDefinitionのスキャン自動検出と依存性注入に関して、これらすべての注釈（つまり、@ Component、@ Service、@ Repository、@ Controller）が同じであることです。別のものの代わりに使用することができ、それでも回避することができます。

@ Component、@ Repository、@ Controller、@ Serviceの違い

@成分

これは、クラスがSpringコンポーネントであることを示す汎用のステレオタイプアノテーションです。

@Componentについて何が特別に
<context:component-scan>のみスキャン@Componentして探していない@Controller、@Serviceと@Repository一般に呼ばれることがあります。それら自体がで注釈されているため、スキャンされ@Componentます。

ただ、見て取り@Controller、@Serviceおよび@Repository注釈の定義を：

@Component
public @interface Service {
    ….
}

@Component
public @interface Repository {
    ….
}

@Component
public @interface Controller {
    …
}

したがって、それはそれを言うのは間違いではありません@Controller、@Serviceと@Repositoryの特殊なタイプです@Component注釈。<context:component-scan>それらを拾い上げ、次のクラスをBeanとして登録します@Component。

特別なタイプのアノテーションもスキャンされます。それ自体がアノテーションで@Componentアノテーションされているため@Componentです。つまり、アノテーションもsです。独自のカスタムアノテーションを定義し、でアノテーションを付けると@Component、それもスキャンされます<context:component-scan>

@リポジトリ

これは、クラスがデータリポジトリを定義することを示します。

@Repositoryの何が特別なのですか？

これが注釈ベースの構成であることを指摘することに加えて、@Repositoryの仕事は、プラットフォーム固有の例外をキャッチし、それらをSpringの統合された未チェックの例外の1つとして再スローすることです。このためPersistenceExceptionTranslationPostProcessorに、Springのアプリケーションコンテキストに次のように追加する必要があるが提供されます。

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

このBeanポストプロセッサは、注釈が付けられたBeanにアドバイザを追加し@Repositoryて、プラットフォーム固有の例外がキャッチされ、Springの未チェックのデータアクセス例外の1つとして再スローされるようにします。

@コントローラ

この@Controller注釈は、特定のクラスがコントローラーの役割を果たすことを示しています。@Controller注釈は、その役割を示し、注釈付きクラスのステレオタイプとして機能します。

@Controllerの何が特別なのですか？

同じように見えても、このアノテーションを他の@Serviceやと切り替えることはできません@Repository。ディスパッチャーは、注釈が付けられたクラスをスキャンし、注釈が付けられたクラスをその内部で@Controller検出@RequestMappingします。我々は使用することができ@RequestMapping、そのクラスでアノテートされているメソッドのみに/上@Controller、それが意志しないと仕事@Component、@Service、@Repository等...

_{注：クラスがすでにBeanとして登録されている場合は、アノテーション@Beanを通じて@Component、または@Serviceアノテーションなどを介して、@RequestMappingクラスにもアノテーションが付いている場合に選択できます@RequestMapping。しかし、それは別のシナリオです。}

@サービス

@Service Beanは、ビジネスロジックを保持し、リポジトリレイヤーでメソッドを呼び出します。

@Serviceの特別な点は何ですか？

それがビジネスロジックを保持していることを示すために使用されているという事実を除けば、この注釈には他に目立つものはありません。しかし、誰が知っているか、Springは将来さらに例外的な機能を追加する可能性があります。

ほかに何か？

将来的には、上記と同様に春はのための特別な機能を追加でき@Service、@Controllerそして@Repositoryその階層化規則に基づきます。したがって、常に規約を尊重し、レイヤーに沿って使用することをお勧めします。

それらはほとんど同じです。それらはすべて、クラスがSpring Beanであることを意味します。@Service、@Repositoryおよび@Controller専門です@Componentの。それらを使用して特定のアクションを実行することを選択できます。例えば：

• @Controller Beanはspring-mvcで使用されます
• @Repository Beanは永続化例外翻訳の対象です

もう1つは、コンポーネントを意味的に異なるレイヤーに指定することです。

@Component提供されることの1つは、他の注釈に注釈を付けて、と同じように使用できること@Serviceです。

たとえば最近私は作った：

@Component
@Scope("prototype")
public @interface ScheduledJob {..}

したがって、注釈が付けられたすべてのクラス@ScheduledJobは春豆であり、それに加えて、クオーツジョブとして登録されます。特定のアノテーションを処理するコードを提供するだけです。

@Componentは次と同等です

<bean>

@ Service、@ Controller、@ Repository = {@Component +いくつかの特別な機能}

つまり、サービス、コントローラ、リポジトリは機能的に同じです。

3つのアノテーションは、アプリケーションの「レイヤー」を区切るために使用されます。

• コントローラは、ディスパッチ、転送、サービスメソッドの呼び出しなどを実行します。
• サービス保留ビジネスロジック、計算など
• リポジトリはDAO（データアクセスオブジェクト）であり、データベースに直接アクセスします。

では、なぜそれらを分離するのかを尋ねてみてください（AOPアスペクト指向プログラミングを知っていると思います）

DAOレイヤーのアクティビティのみを監視するとします。DAOのすべてのメソッドが呼び出される前後にログを記録するアスペクト（Aクラス）クラスを記述します。3つの異なるレイヤーがあり、混在していないため、AOPを使用してログを記録できます。

したがって、DAOメソッドの「前後」、「前」、「後」のDAOのロギングを行うことができます。そもそもDAOがあったからです。あなたがたった今達成したことは、懸念や仕事の分離です。

アノテーション@Controllerが1つしかない場合を想像してみてください。このコンポーネントには、ディスパッチ、ビジネスロジック、およびデータベースへのアクセスがすべて混在しているため、ダーティコードになります。

上記は非常に一般的なシナリオの1つですが、3つのアノテーションを使用する理由は他にもたくさんあります。

春@Componentに@Serviceは、、、@Controllerおよび@Repositoryステレオタイプの注釈に使用されています。

@Controller:ここで、プレゼンテーションページからのリクエスト マッピングが完了します。つまり、プレゼンテーションレイヤーは他のファイルに移動せず、直接@Controllerクラスに移動し、@RequestMapping必要に応じてメソッド呼び出しの前に書き込まれた注釈内の要求されたパスをチェックします。

@Service：すべてのビジネスロジックがここにあります。つまり、データ関連の計算とすべてです。この永続化メソッドをユーザーが直接呼び出さないビジネスレイヤーのこのアノテーションは、このアノテーションを使用してこのメ​​ソッドを呼び出します。ユーザーのリクエストに応じて@Repositoryをリクエストします

@Repository：これは、データベースからデータを取得するために使用されたアプリケーションの永続層（データアクセス層）です。つまり、データベースに関連するすべての操作はリポジトリによって行われます。

@Component -他のコンポーネント（RESTリソースクラスなど）にコンポーネントステレオタイプの注釈を付けます。

注釈付きクラスが「コンポーネント」であることを示します。このようなクラスは、注釈ベースの構成とクラスパススキャンを使用する場合の自動検出の候補と見なされます。

他のクラスレベルのアノテーションもコンポーネントを識別するものと見なされます。通常は、特殊な種類のコンポーネントです。たとえば、@ RepositoryアノテーションやAspectJの@Aspectアノテーションなどです。

Spring 2.5では、@ Component、@ Service、@ Controllerのステレオタイプアノテーションが導入されています。@Componentは、Springで管理されるコンポーネントの一般的なステレオタイプとして機能します。一方、@ Repository、@ Service、および@Controllerは、より具体的なユースケース（たとえば、それぞれ永続性、サービス、プレゼンテーションレイヤー）の@Componentの特殊化として機能します。つまり、コンポーネントクラスに@Componentでアノテーションを付けることができますが、代わりに@ Repository、@ Service、または@Controllerでアノテーションを付けることで、クラスはツールによる処理やアスペクトとの関連付けにより適したものになります。たとえば、これらのステレオタイプアノテーションは、ポイントカットの理想的なターゲットになります。もちろん、@ Repository、@ Service、および@Controllerが、Spring Frameworkの将来のリリースで追加のセマンティクスを持つ可能性もあります。したがって、サービスレイヤーに@Componentと@Serviceのどちらを使用するかを決定する場合は、@ Serviceの方が適しています。同様に、上記のように、@ Repositoryは永続層での自動例外変換のマーカーとして既にサポートされています。

@Component – Indicates a auto scan component.
@Repository – Indicates DAO component in the persistence layer.
@Service – Indicates a Service component in the business layer.
@Controller – Indicates a controller component in the presentation layer.

リファレンス：-Springのドキュメント-クラスパススキャン、管理対象コンポーネント、Javaを使用した構成の記述

技術的には@Controller、@Service、@Repositoryすべて同じです。それらすべてが拡張されます@Componentます。

Springソースコードから：

注釈付きクラスが「コンポーネント」であることを示します。このようなクラスは、注釈ベースの構成とクラスパススキャンを使用する場合、自動検出の候補と見なされます。

私たちは、直接使用することができ@Component、我々が使用し、それぞれ、すべてのBeanのが、大きなアプリケーションの理解と保守性のために@Controller、@Service、@Repository。

各アノテーションの目的：

1. @Controller->これで注釈が付けられたクラスは、クライアント側からリクエストを受け取ることを目的としています。最初のリクエストはDispatcherサーブレットに送られ、そこから@RequestMappingアノテーションの値を使用して特定のコントローラーにリクエストを渡します。
2. @Service->これで注釈が付けられたクラスは、クライアントから受信するか、データベースからフェッチするデータを操作することを目的としています。データを使用したすべての操作は、このレイヤーで行う必要があります。
3. @Repository->これで注釈されたクラスは、データベースと接続することを目的としています。DAO（データアクセスオブジェクト）レイヤーと見なすこともできます。このレイヤーは、CRUD（作成、取得、更新、削除）操作のみに制限する必要があります。操作が必要な場合は、データを@Serviceレイヤーに送り返す必要があります。

入れ替えれば（の@Repository代わりに使う@Controller）、アプリケーションは正常に動作します。

3つの異なる方法を使用する主な目的は@annotations、エンタープライズアプリケーションにより優れたモジュール性を提供することです。

@Serviceと@Repositoryアノテーションの使用は、データベース接続の観点から重要です。

1. 使用する @Service DB接続のすべてのWebサービスの種類について
2. 使用@RepositoryすべてのストアドプロシージャのDB接続用

適切なアノテーションを使用しないと、ロールバックトランザクションによってオーバーライドされるコミット例外が発生する可能性があります。JDBCトランザクションのロールバックに関連するストレス負荷テスト中に例外が表示されます。

@Repository @Serviceおよび@Controllerは、@ Componentの特殊化として機能し、そのため、@ Serviceを@Componentに置き換えることができますが、この場合、特殊化は失われます。

1. **@Repository**   - Automatic exception translation in your persistence layer.
2. **@Service**      - It indicates that the annotated class is providing a business service to other layers within the application.

これらの注釈はすべて、ステレオタイプの注釈タイプです。これら3つの注釈の違いは、

• @Componentを追加すると、クラスの役割がコンポーネントクラスであることを通知します。これは、ロジックを含むクラスであることを意味しますが、特定のビジネス、永続性、またはコントローラーロジックを含むクラスかどうかは通知しないため、使用しません。この@Componentアノテーションを直接
• @Serviceアノテーションを追加すると、ビジネスロジックで構成されるクラスの役割が
• クラスの上に@Repositoryを追加すると、永続ロジックで構成されるクラスが
• ここで、@ Componentは@ Service、@ Repositoryおよび@Controllerアノテーションの基本アノテーションです

例えば

package com.spring.anno;
@Service
public class TestBean
{
    public void m1()
    {
       //business code
    }
}

package com.spring.anno;
@Repository
public class TestBean
{
    public void update()
    {
       //persistence code
    }
}

• @Serviceorまたは@Repositroyor @Controllerアノテーションをデフォルトで追加するときはいつでも、@Componentアノテーションはクラスの上に存在します

春は、彼らは自動車部品スキャン注釈の4種類を提供し@Component、@Service、@Repositoryおよび@Controller。技術的には、それらの間に違いはありませんが、すべての自動コンポーネントスキャンアノテーションは、特別な目的で定義されたレイヤー内で使用する必要があります。

@Component：これは基本的な自動コンポーネントスキャン注釈であり、注釈付きクラスが自動スキャンコンポーネントであることを示します。

@Controller：注釈付きクラスは、それがコントローラーコンポーネントであり、主にプレゼンテーションレイヤーで使用されることを示します。

@Service：注釈付きクラスがビジネスレイヤーのサービスコンポーネントであることを示します。

@Repository：このアノテーションは永続化レイヤー内で使用する必要があります。これはデータベースリポジトリのように機能します。

@Componentこのアノテーションには今後の特定の動作が含まれる可能性があるため、クラスにアノテーションを付ける際には、より特殊な形式を選択する必要があります。

これはJava標準に従って答えることができます

SpringでJSR-330サポートされるようになったを参照すると、@NamedBeanの定義にしか使用できません（Somehow @Named=@Component）。この規格に準拠したので、（のようなステレオタイプを定義するためには使用がないことがあるようで@Repository、@Service、@Controllerカテゴリ豆には）。

しかし、これらのさまざまな注釈を特定の用途に応じて異なる方法でスプリングユーザーに使用します。次に例を示します。

1. 有能な開発者がより適切なカテゴリを定義できるように支援します。この分類は、場合によっては役立つことがあります。（たとえば、を使用している場合aspect-oriented、これらはpointcuts）
2. @Repository アノテーションは、Beanにいくつかの機能を追加します（Bean永続化レイヤーへの一部の自動例外変換）。
3. Spring MVCを使用している場合、は、@RequestMappingによって注釈が付けられたクラスにのみ追加でき@Controllerます。

RESTリソースクラスなど、@ Componentを使用して他のコンポーネントに注釈を付けます。

@Component
public class AdressComp{
    .......
    ...//some code here    
}

@Componentは、Springが管理するコンポーネントの一般的なステレオタイプです。

@ Controller、@ Service、および@Repositoryは、特定のユースケース向けの@Componentの特殊化です。

Springの@Component

間に違いはありません@Component、@Service、@Controller、@Repository。 @ComponentMVCのコンポーネントを表すGenericアノテーションです。ただし、サービスレイヤーコンポーネント、永続化レイヤーコンポーネント、プレゼンテーションレイヤーコンポーネントなど、MVCアプリケーションの一部としていくつかのコンポーネントがあります。それらを区別するために、Springの人々は他の3つの注釈も与えています。

• 永続層コンポーネントを表すには： @Repository
• サービス層コンポーネントを表すには： @Service
• プレゼンテーションレイヤーコンポーネントを表すには： @Controller
• または@Component、それらすべてに使用できます。

@Componentまたは@Repositoryまたは@serviceを交換しても

それは同じように動作しますが、1つの側面は、コンポーネントまたは@サービスを使用する場合、リポジトリの代わりにDAOに関連する特定の例外をキャッチできないことです。

Spring 4の最新バージョン：

@Repositoryアノテーションは、リポジトリ（データアクセスオブジェクトまたはDAOとも呼ばれます）の役割またはステレオタイプを満たすクラスのマーカーです。このマーカーの使用には、20.2.2項「例外の変換」で説明されている例外の自動変換があります。

Springは、@ Component、@ Service、および@Controllerのステレオタイプアノテーションを提供しています。@Componentは、Springで管理されるコンポーネントの一般的なステレオタイプです。@ Repository、@ Service、および@Controllerは、それぞれ永続性、サービス、プレゼンテーションレイヤーなど、より具体的なユースケース向けの@Componentの特殊化です。したがって、コンポーネントクラスに@Componentで注釈を付けることができますが、代わりに@ Repository、@ Service、または@Controllerで注釈を付けることにより、クラスはツールによる処理またはアスペクトとの関連付けにより適切になります。たとえば、これらのステレオタイプアノテーションは、ポイントカットの理想的なターゲットになります。また、Spring Frameworkの将来のリリースでは、@ Repository、@ Service、および@Controllerに追加のセマンティクスが含まれる可能性があります。したがって、サービスレイヤーに@Componentと@Serviceのどちらを使用するかを選択する場合は、@ Serviceの方が適しています。同様に、上記のように、@ Repositoryは永続層での自動例外変換のマーカーとして既にサポートされています。

@Component：クラス@Componentに注釈を付けると、クラスがBeanであることをhibernateに伝えます。

@Repository：クラス@Repositoryに注釈を付けると、休止状態がDAOクラスであり、DAOクラスとして扱われることが通知されます。チェックされていない例外（DAOメソッドからスローされたもの）をSpringへの変換に適格にすることを意味しますDataAccessException。

@Service：これにより、HibernateはServiceクラスである@Transactionalなどのサービスクラスアノテーションになるので、HibernateはそれをServiceコンポーネントとして扱います。

プラス@Serviceはの進歩です@Component。CustomerServiceXML Bean構成方法を選択しなかったため、Beanクラス名がであると想定して、Bean @Componentとして注釈を付け、Beanであることを示します。つまり、Beanオブジェクトを取得している間、CustomerService cust = (CustomerService)context.getBean("customerService");デフォルトでは、Springはコンポーネントの最初の文字を小文字にします（「CustomerService」から「customerService」へ）。そして、このコンポーネントを「customerService」という名前で取得できます。ただし@Service、Beanクラスにアノテーションを使用する場合は、次の方法で特定のBean名を提供できます。

@Service("AAA")
public class CustomerService{

あなたはBeanオブジェクトを取得することができます

CustomerService cust = (CustomerService)context.getBean("AAA");

@Component アノテーション付きBeanをスキャンしてDIコンテナーで使用できるようにする最上位の汎用アノテーションです。

@Repository 特別な注釈であり、DAOクラスからのすべての未チェックの例外を変換する機能をもたらします

@Service特別な注釈です。現在のところ新機能はありませんが、Beanの意図が明確になっています

@ControllerはBeanをMVCに認識させる特殊なアノテーションであり、同様の@RequestMappingすべてのアノテーションを使用できます。

ここではより多くのです詳細は

@Service、春の文書を引用します

注釈付きクラスが「サービス」であり、ドメイン駆動設計（Evans、2003）によって「カプセル化された状態のない、モデル内でスタンドアロンのインターフェースとして提供される操作」として最初に定義されたことを示します。 また、クラスが「ビジネスサービスファサード」（コアJ2EEパターンの意味で）、または類似したものであることを示す場合もあります。この注釈は汎用のステレオタイプであり、個々のチームはセマンティクスを絞り込み、必要に応じて使用できます。

エリック・エヴァンスによるドメイン駆動設計を見ると、

SERVICEは、ENTITIESおよびVALUE OBJECTSのように、カプセル化された状態なしで、モデル内でスタンドアロンのインターフェースとして提供される操作です。サービスは、テクニカルフレームワークでは一般的なパターンですが、ドメインレイヤーにも適用できます。ネームサービスは、他のオブジェクトとの関係を強調します。ENTITIESやVALUE OBJECTSとは異なり、クライアントに対して何ができるかという観点から純粋に定義されています。SERVICEは、エンティティではなくアクティビティー、つまり名詞ではなく動詞にちなんで名付けられる傾向があります。サービスは、抽象的で意図的な定義を持つことができます。オブジェクトの定義とは異なるフレーバーを持っているだけです。サービスには依然として責任が定義されている必要があり、その責任とそれを実行するインターフェースはドメインモデルの一部として定義する必要があります。オペレーション名は、UBIQUITOUS LANGUAGEから取得するか、その中に導入する必要があります。パラメータと結果はドメインオブジェクトである必要があります。SERVICESは慎重に使用する必要があり、ENTITIESおよびVALUE OBJECTSのすべての動作を取り除くことはできません。しかし、操作が実際に重要なドメインの概念である場合、サービスはモデル駆動型設計の自然な部分を形成します。モデルでは、実際には何も表さない偽装オブジェクトとしてではなく、SERVICEとして宣言されているため、スタンドアロン操作によって誤解が生じることはありません。サービスは、モデル駆動型設計の自然な部分を形成します。モデルでは、実際には何も表さない偽装オブジェクトとしてではなく、SERVICEとして宣言されているため、スタンドアロン操作によって誤解が生じることはありません。サービスは、モデル駆動型設計の自然な部分を形成します。モデルでは、実際には何も表さない偽装オブジェクトとしてではなく、SERVICEとして宣言されているため、スタンドアロン操作によって誤解が生じることはありません。

そして、Repositoryエリック・エヴァンスによると、

REPOSITORYは、特定のタイプのすべてのオブジェクトを概念セット（通常はエミュレート）として表します。より複雑なクエリ機能を除いて、コレクションのように機能します。適切なタイプのオブジェクトが追加および削除され、リポジトリの背後にある機構がオブジェクトを挿入するか、データベースから削除します。この定義は、ライフサイクルの初期から終わりまで、AGGREGATESのルーツへのアクセスを提供するための一連の責任のまとまりを集めています。

what-the-difference-between-component-repository-service-annotationsを説明するのに十分な答えがあります。違いを共有したいと思います@Controller & @RestController

@Controller 対 RestController

@RestController：

• この注釈は、の特殊なバージョンで@Controller追加された @Controllerと@ResponseBody自動的に注釈。したがって@ResponseBody、マッピングメソッドに追加する必要はありません。つまり、 @ResponseBodyデフォルトでアクティブになります。
• 使用@RestControllerするとビューを返すことができません（ ViewresolverSpring / Spring-Bootで使用）
• @RestControllerまた、応答をJSON/XML automaticallyasに変換し@ResponseBody、返されたオブジェクトを本文に含まれる可能性があるものに変換します。e.g. JSON or XML

@Controller

• @ControllerクラスをSpring MVCコントローラーとしてマークするために使用されます。この注釈はの特別なバージョンで@Componentあり、クラスパススキャンに基づいてコントローラークラスを自動検出できるようにします。
• @Controller Spring web MVCでビューを返すことができます。

より詳細なビュー

リポジトリとサービスは、コンポーネントアノテーションの子です。したがって、それらはすべてComponentです。リポジトリとサービスはそれを拡張するだけです。正確には？ サービスにはイデオロギーの違いしかない：私たちはそれをサービスに使用します。リポジトリには特定の例外ハンドラがあります。

ステレオタイプの説明：

• @Service-すべてのサービスクラスに@Serviceアノテーションを付けます。このレイヤーは作業単位を認識しています。すべてのビジネスロジックはServiceクラスにあります。通常、サービス層のメソッドはトランザクションでカバーされます。サービスメソッドから複数のDAO呼び出しを行うことができます。1つのトランザクションが失敗すると、すべてのトランザクションがロールバックされます。
• @Repository-すべてのDAOクラスに@Repositoryで注釈を付けます。すべてのデータベースアクセスロジックはDAOクラスにある必要があります。
• @Component -他のコンポーネント（RESTリソースクラスなど）にコンポーネントステレオタイプの注釈を付けます。
• @Autowired -@Autowiredアノテーションを使用して、Springに他のBeanをクラスに自動接続させる。

@ComponentSpringで管理されるコンポーネントの一般的なステレオタイプです。@Repository、@Service、および@Controllerの特殊化され@Component、それぞれのより具体的なユースケースのために、例えば、持続性、サービス、およびプレゼンテーション層で、。

もともとここで答えた。

@ Component、@ Repository、@ Controller、@ Serviceアノテーションの違い

@Component –汎用的で、アプリケーション全体で使用できます。
@Service –サービス層レベルでクラスに注釈を付けます。
@Controller –主にSpring MVCで使用されるプレゼンテーション層レベルでクラスに注釈を付けます。
@Repository –データベースリポジトリとして機能する永続化レイヤーでクラスに注釈を付けます。

@Controller= @Component（内部アノテーション）+プレゼンテーションレイヤー機能
@Service= @Component（内部アノテーション）+サービスレイヤー機能
@Component=実際のコンポーネント（Beans）
@Repository= @Component（内部アノテーション）+データレイヤー機能（ドメインBeanの処理に使用）

Springフレームワークでは、ステレオタイプアノテーションと呼ばれる特別なタイプのアノテーションが提供されます。これらは次のとおりです。

@RestController- Declare at controller level.
@Controller – Declare at controller level.
@Component – Declare at Bean/entity level.
@Repository – Declare at DAO level.
@Service – Declare at BO level.

上記で宣言された注釈は特別です<context:component-scan>。xxx-servlet.xmlファイルに追加すると、Springは、コンテキストの作成/ロード段階で、上記の注釈が付けられたクラスのオブジェクトを自動的に作成します。

@Component、@ Repository、@ Service、@Controller：

@Component春によって管理されるコンポーネントのための一般的なステレオタイプである@Repository、@Serviceと@Controllerされ@Component、より具体的な用途のために特化：

• @Repository 持続のために
• @Service サービスおよびトランザクション用
• @Controller MVCコントローラー用

なぜ使用@Repository、@Service、@Controllerオーバー@Component？@Componentを使用してコンポーネントクラスをマークできますが、代わりに、期待される機能に適応する代替を使用します。私たちのクラスは、それぞれの特定のケースで期待される機能により適しています。

アノテーションが付けられたクラス@Repositoryは、org.springframework.dao.DataAccessExceptionを使用した、より優れた翻訳と読み取り可能なエラー処理を備えています。データにアクセスするコンポーネント（DataAccessObjectまたはDAO）の実装に最適です。

@ControllerSpring Web MVCアプリケーションでコントローラーの役割を果たすアノテーション付きクラス

付きの注釈付きクラスは@Service、ビジネスロジックサービスで役割を果たします。例として、DAO Manager（Facade）のFacadeパターンとトランザクション処理があります。

ここに提示された答えは、技術的には大部分が正しいですが、応答リストが長く、これが一番下になりますが、誰かがそれにつまずいて何かから貴重なことを学ぶ場合に備えて、ここにも実際に正しい応答を配置する価値があると思いましたそれ。それは残りの答えが間違っているということではなく、それらが正しくないというだけです。そして、荒らしの大群を止めるために、はい、技術的にこれらの注釈は事実上同じものであり、春5までさえ最も交換可能であることを知っています。さて、正しい答えについては：

これら3つの注釈は完全に異なるものであり、互換性はありません。1つではなく3つあるため、それがわかります。それらは交換可能であるようには意図されておらず、優雅さと利便性からそのように実装されているだけです。

現代のプログラミングは、発明、芸術、技術、およびコミュニケーションであり、比率はさまざまです。コードは通常、書き込まれるよりもはるかに頻繁に読み取られるため、通信ビットは通常非常に重要です。プログラマーは、技術的な問題を解決しようとしているだけでなく、コードを読む将来のプログラマーにも意図を伝えようとしています。これらのプログラマーはあなたの母国語もあなたの社会的環境も共有していないかもしれません、そして彼らが将来50年後にあなたのコードを読んでいる可能性があります（あなたが思うほどそうではありません）。その先まで効果的にコミュニケーションをとることは難しい。したがって、私たちが利用できる最も明確で、最も効率的で、正しい、コミュニケーション可能な言語を使用することが重要です。

たとえば@Repository、リポジトリではなく、リポジトリを作成するときに使用することが重要です@Component。後者は、リポジトリを検討していることを示すものではないため、リポジトリに対する注釈の選択としては非常に貧弱です。リポジトリもSpring-Beanであると想定できますが、コンポーネントがリポジトリであるとは想定できません。と@Repository私たちは私たちの言語で明確かつ具体的です。これはリポジトリであることを明確に述べています。と@Component読み取るコンポーネントのタイプを決定するのはリーダーに任せます。意味を推測するには、クラス全体（およびおそらくサブクラスとインターフェースのツリー）を読み取る必要があります。その後、クラスは読者によってリポジトリではないと誤って解釈される可能性があり、これがリポジトリであることを十分に知っていた私たちが私たちの言語で特定できなかったので、私たちはこの間違いの一部の原因でしたそして私たちの意図を効果的に伝えます。

他の例には触れませんが、できる限り明確に説明します。これらの注釈は完全に異なるものであり、その意図に従って適切に使用する必要があります。@Repositoryストレージリポジトリ用であり、他のアノテーションは正しくありません。@Serviceサービス用であり、他の注釈は正しくありません。@Componentリポジトリでもサービスでもないコンポーネント用であり、代わりにこれらのいずれかを使用することも正しくありません。それはコンパイルされるかもしれません、それはあなたのテストを実行してパスするかもしれません、しかしそれは間違っているでしょう、そしてあなたがこれをするならあなたは（専門的に）あなたのことをあまり考えません。

これの例は春を通してあります（そしてプログラミング全般）。@ControllerREST APIを作成するときに@RestControllerは、を使用できるため、使用しないでください。が有効な代替である@RequestMapping場合@GetMappingは使用しないでください。等等読者に意図を伝えるために、最も具体的で正確な言語を選択する必要があります。そうしないと、システムにリスクが発生し、リスクが伴います。

この図を簡略化するために、ユースケースごとに専門性を検討してみましょう。これらの注釈は注入に使用されます。つまり、私が文字通り「注入に使用されました」ということです。つまり、依存性注入「DI」の使用方法を知っていて 、すると、常にこれらの注釈を探し、クラスにこれらのステレオタイプで注釈を付けることにより、DIコンテナーにそれらをスキャンして他の場所でのインジェクションの準備ができるように通知することになります。これは実用的なターゲットです。

次に、それぞれに移動しましょう。最初の@Service、特定のビジネスケースのロジックを構築している場合は、ビジネスロジックが含まれる場所でそれを分離する必要があります。このサービスは通常のクラスですが、必要に応じてインターフェイスとして使用することもできます。この

@Service
public class Doer {
   // Your logic 
}

// To use it in another class, suppose in Controller 
@Controller
public class XController {
 // You have to inject it like this 
 @Autowired 
 private Doer doer;
}

それらを注入するときはすべて同じ方法です。@ Repositoryは、リポジトリパターンリポジトリデザインパターンの実装を適用するインターフェイスです。通常、これは、データストアまたはデータベースを処理しているときに使用されます。データベース操作を処理するための準備が整っている。CrudRepository、JpaRepositoryなどにすることができます 。

// For example
public interface DoerRepository implements JpaRepository<Long, XEntity> {}

最後に@Component、これはSpringで登録されたBeanの一般的な形式です。つまり、Springは常に、登録される@ComponentでマークされたBeanを探します。@ Serviceと@Repositoryはどちらも@Componentの特殊なケースですが、一般的な使用例コンポーネントの場合は、直接的なビジネスケースをカバーするためではなく、純粋に技術的なものを作成する場合です。日付のフォーマットや特別なリクエストのシリアル化メカニズムの処理など。

@Componentは、設定クラスで@Beanアノテーションとして機能し、SpringコンテキストでBeanを登録します。また、@ Service、@ Repository、および@Controllerアノテーションの親です。

@Serviceは@Componentアノテーションを拡張し、名前の違いのみを持ちます。

@Repository - @Component注釈を拡張し、内のすべてのデータベースの例外翻訳 DataAccessExceptionを。

@Controller -MVCパターンでコントローラーとして機能します。ディスパッチャーは、このような注釈付きクラスをスキャンして、マップされたメソッドを探し、@ RequestMapping注釈を検出します。

@Component
@Controller
@Repository
@Service
@RestController

これらはすべてStereoTypeアノテーションです。これは、クラスをiocコンテナのSpring Beanとして作成するのに役立ちます。