どっちがいい?spring mvc では、@Controller
すべてのController
クラスに使用されます。マーカー インターフェイスを使用できたでしょうか。なぜ彼らは注釈アプローチを選択したのですか? さらに良いことに、パッケージ内の任意のクラスを Controller クラスと見なすことができるように、controller-scan
似たようなものを持つことができます。component-scan
同様にservice-scan
、repository-scan
xml で定義できます。
2 に答える
技術的には、マーカーインターフェイスでも同じ効果が得られると思います。問題は、マーカーインターフェイスがクラスに制限されており、属性やメソッドに使用できないことです。
@Autowired
Springは、属性(eg )またはメソッド(eg@RequestMapping
または)にメタデータを追加するためにアノテーションを使用しています@Transactional
。したがって、メタデータをクラス(@Controller
またはなど@Service
)に追加するために同じアプローチを使用することは一貫しています。
Springは、提供されたアノテーションの使用を強制しないことに注意してください。@Controller
と@RequestMapping
は、ハンドラーマッピングを定義するためのデフォルトの方法にすぎません。理論的には、着信要求をメソッド呼び出しにマッピングする独自の方法を考え出すことができます。
どちらも最初は同じ目的を果たします。何かをマークして発見する。
注釈は、より直接的なマーキングを目的としています。マーカー インターフェイスは実際には型を定義しますが、その型の変数を宣言すると、それに対してできることは何もありません。注釈は型を作成しません。注釈に意味を与えるのは、注釈を処理するコード次第です。
結局のところ、これは好みの問題です。
注釈には、追加のメタデータを保存できるという利点があります。@Named("foo") のように。マーカー インターフェイスには、すべてのアイテムがマーカー インターフェイスを持つことを保証するコレクションを作成できるという利点があります。たとえば、ジェネリック型または変数型に特定の注釈が必要であるという制約はありません。
メソッドのアノテーションとインターフェースのメソッドのアノテーションについては、インターフェースのメソッドには実装が必要であるという問題があります (Java 8 では、これは厳密にはもう必要ありません)。正しいメソッド署名を強制しません。つまり、一部の注釈には void foo(Bar bar) などのメソッド シグネチャが必要ですが、この事実はドキュメント (存在する場合) で調べる必要があります。