Soru İlkbaharda @Component, @Repository & @Service ek açıklamaları arasındaki fark nedir?


kutu @Component, @Repository ve @Service ek açıklamaları Baharda birbirinin yerine kullanılabilir mi yoksa bir notasyon cihazı gibi davranmanın yanında herhangi bir özel işlev sağlıyor mu?

Başka bir deyişle, bir Hizmet sınıfım varsa ve ek açıklamayı @Service için @ComponentYine de aynı şekilde davranacak mı?

Veya ek açıklama, sınıfın davranışını ve işlevselliğini de etkiler mi?


1523
2017-07-26 09:10


Menşei


Microsoft arka planında bir geliştirici olarak, eski MS SmartClientSoftwareFactory çerçevesindeki hizmetlerin anlamsal tanımını hatırlıyorum (şimdi dağıtılmış masaüstü uygulamaları için uzun zamandır kabul edilmeyen karmaşık bir çerçeve). Bu tanım (güzel belgelenmiş tarafından Rich Newman, hizmetleri, argüman olarak iletilen diğer nesnelerde iş mantığı işlemlerini gerçekleştirmek için kullanılan, tek nokta kapsamıyla, vatansız yeniden kullanılabilir nesneler olarak tanımlamıştır. Ben bahar hizmetlerini aynı şekilde görmeye eğilimliyim - Ivaylo Slavov
Önemli değil! Sizin için her ne işe yarıyorsa :) Ben her zaman bu bahar hakkında nefret ediyorum, her zaman sizin için "kurallar" tanımlamak eğilimindedir, bu sadece uygulamanıza önemsiz değer katar. Bahar, kendi başına büyük bir yığınla gelir. - TriCore
@TriCore Sprting bir çerçeve, sizin için "kuralları" tanımlamanızdır :) - Walfrat


Cevaplar:


itibaren Bahar Belgeleri:

İlkbahar 2.0 ve sonrasında @Repository ek açıklama için bir işaretçi   rolü veya klişeyi yerine getiren herhangi bir sınıf (Veri olarak da bilinir)   Deponun Erişim Nesnesi veya DAO). Bu markanın kullanımları arasında   istisnaların otomatik çevirisi.

İlkbahar 2.5, daha fazla stereotype ek açıklamaları sunar: @Component,    @Service, ve @Controller. @Component herhangi bir jenerik klişe   Yaylı bileşen. @Repository, @Service, ve @Controller Hangi   uzmanlık @Component daha özel kullanım durumları için   örnek, kalıcılık, servis ve sunum katmanlarında,   sırasıyla.

Bu nedenle, bileşen sınıflarınızı @Component,   ama onları ekleyerek @Repository, @Serviceveya @Controller   bunun yerine, sınıflarınız araçları tarafından işlenmek için daha uygun   veya yönleriyle ilişkilendirme. Örneğin, bu stereotype ek açıklamaları   pointcuts için ideal hedefler yapmak.

Böylece, arasında seçim yapıyorsanız @Component veya @Service için   hizmet tabakanız @Service açıkça daha iyi bir seçimdir. Benzer şekilde,   yukarıda belirtildiği gibi, @Repository zaten bir işaretçi olarak destekleniyor   Kalıcı tabakanızda otomatik istisna çeviri.

┌────────────┬─────────────────────────────────────────────────────┐
│ 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)      │
└────────────┴─────────────────────────────────────────────────────┘

1119
2017-08-01 10:20



@WebServlet'e @Controller (veya @Component) eklemek mantıklı olur mu? Bu bir Spring MVC kontrolörü değil, ama kavramsal olarak en yakın eşleşme. Servlet filtreleri nedir? - Rick
"@Repository, kalıcılık katmanınızda otomatik istisna çevirisi için bir işaretçi olarak zaten destekleniyor." anlamına gelmek? - Jack
Bu ek açıklamaların AOP için iyi hedefler olduğu gerçeğine atıfta bulunurken, diğer ek açıklamalar henüz bir noktayı tanımlamazken, bunu gelecekte de yapabilirler. Öte yandan @Repository halihazırda bir pointcut için bir hedeftir. Bu nokta kesimi, istisna çevirileri için kullanılır, yani sıkı bağlamayı önlemek için, teknolojiye özgü istisnaların daha jenerik Yay-temelli olanlara çevrilmesi. - stivlo
@stivlo: Ben hala 'stereotype' terimini anlamaya çalıştım, hala anlamadım. Bu terminolojiyi anlamama yardımcı olabilir misiniz? Çok yardımcı oluyor ve çok teşekkür ederim - Premraj
stackoverflow.com/questions/14756486/... - stivlo


Cevapların birçoğu, bu ek açıklamaların ne için kullanıldığını zaten belirttiğimiz için, bunlar arasında bazı küçük farklılıklara odaklanacağız.

İlk önce Benzerlik 

Tekrar vurgulamaya değer ilk nokta, BeanDefinition için tarama otomatik algılama ve bağımlılık enjeksiyon ile ilgili olarak tüm bu ek açıklamalar (viz., @Component, @Service,   @Repository, @Controller) aynıdır. Bir tane kullanabiliriz   bir başkası ve hala yolumuza girebiliriz.


@Component, @Repository, @Controller ve @Service arasındaki farklar

@Bileşen

Bu, sınıfın bir yay bileşeni olduğunu belirten genel amaçlı bir stereotip açıklamadır.

@Component hakkında özel nedir?
<context:component-scan> sadece tarar @Component ve aramıyor @Controller, @Service ve @Repository Genel olarak. Taranıyorlar çünkü kendileri ek açıklamada bulunuyorlar @Component.

Sadece bir göz at @Controller, @Service ve @Repository ek açıklama tanımları:

@Component
public @interface Service {
    ….
}

@Component
public @interface Repository {
    ….
}

@Component
public @interface Controller {
    …
}

Böylece, bunu söylemek yanlış olmaz. @Controller, @Service ve @Repository özel türleri @Component Ek açıklama. <context:component-scan> Onları alır ve aşağıdaki sınıfları fasülyeler olarak kaydeder, tıpkı açıklamalı @Component.

Taranıyorlar çünkü kendileri ek açıklamada bulunuyorlar @Component Ek açıklama. Eğer kendi özel notumuzu tanımlarsak ve @Componentsonra da taranır <context:component-scan>


@Repository

Bu, sınıfın bir veri havuzunu tanımladığını gösterir.

@Repository hakkında özel nedir? 

Bunun bir olduğuna işaret etmenin yanı sıra Ek açıklama tabanlı yapılandırma, @Repositoryİşin görevi, Platform'a özel istisnaları yakalamak ve bunları Spring’in birleştirilmiş denetlenmemiş istisnasından biri olarak yeniden atamaktır. Ve bunun için sağladık PersistenceExceptionTranslationPostProcessorbizim Spring’in uygulama içeriğine şunları eklememiz gerekiyor:

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

Bu fason post işlemci, ek açıklamada bulunan herhangi bir fasülyeye bir danışman ekliyor @Repository Böylece, platforma özgü istisnalar yakalanır ve daha sonra Spring’in kontrol edilmemiş veri erişimi istisnalarından biri olarak yeniden çizilir.


@Controller

@Controller ek açıklama, belirli bir sınıfın bir denetleyici rolüne hizmet ettiğini belirtir. @Controller ek açıklama, açıklamalı sınıfın rolünü belirten bir stereotype işlevi görür.

@Controller hakkında özel nedir? 

Bu notu başka biriyle değiştiremeyiz @Service veya @Repository, aynı görünmelerine rağmen. Dağıtıcı, açıklamalı notları tarar. @Controller ve algılar @RequestMapping içlerinde ek açıklamalar. Sadece kullanabiliriz @RequestMapping üzerinde @Controller açıklamalı sınıflar.


@Hizmet

@Services Depo katmanında iş mantığını ve çağrı yöntemini tutun.

@Service hakkında özel nedir? 

İş mantığını tuttuğunu belirtmek için kullanıldığından başka, bu açıklamanın sağladığı dikkate değer bir özellik yoktur, fakat kim bilir, bahar gelecekte bazı istisnai durumlar ekleyebilir.


Başka?

Yukarıda da belirtildiği gibi, gelecekte Spring, özel işlevler eklemeyi seçebilir. @Service, @Controller ve @Repository katmanlama sözleşmelerine göre. Bu nedenle, sözleşmeye saygı duymak ve bunları katmanlarla uyumlu olarak kullanmak her zaman iyi bir fikirdir.


426
2017-07-24 06:43



Bu benim en sevdiğim. Bu soru için bolca iyi cevaplar var ve hepsini okumanı tavsiye ederim, ancak bu ek açıklamalar arasındaki farklılıkları vurgular. - Adrian Cosma
güzel kısa temiz açıklama - VedX
Bu cevabı takdir edecek bir kelime yok. Her bir ifade, anlaşılması için çok açık ve kolaydır. - MAC
Burada verilen açıklama kısa ve özlüdür. Bu çok uzaktaki tek tatmin edici cevap - Julius Krah
Cevap bu. - Alessandro


Neredeyse aynılar - hepsi sınıfın bir Spring fasulyesi olduğu anlamına gelir. @Service, @Repository ve @Controller uzmanlaşmak @Components. Onlarla belirli eylemler gerçekleştirmeyi seçebilirsiniz. Örneğin:

  • @Controller fasulye bahar-mvc tarafından kullanılır
  • @Repository fasulye ısrar istisnai çeviri için uygundur

Başka bir şey, bileşenleri farklı katmanlara semantik olarak atamanızdır.

Bir şey bu @Component teklifler, diğer ek açıklamaları ona ekleyebilir ve ardından bunları @Service.

Örneğin yakın zamanda yaptım:

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

Yani tüm sınıflar açıklamalı @ScheduledJob bahar fasulyesi ve buna ek olarak kuvars işleri olarak kayıtlıdır. Sadece belirli bir notu işleyen kod sağlamanız gerekir.


388
2017-07-26 09:16



@Component sadece bir bahar fasulyesi anlamına gelir, bunun için başka bir amaç var mı? - kapil das
@Component fasulye, bahar konteyner tarafından otomatik olarak algılanabilir. Fasulye, yapılandırma dosyasında tanımlamanıza gerek yoktur; bu, çalışma zamanında otomatik olarak Spring tarafından algılanır. - Akash5288
Ben özellikle @Scope (proxyMode = ScopedProxyMode.//MODE) ile birleştiğinde genel @Component'i çok seviyorum. - Eddie B


@Component eşdeğerdir

<bean>

@Service, @Controller, @Repository = {@Component + biraz daha özel işlevsellik}

Bu Servis, Denetleyici ve Havuzun işlevsel olarak aynı olduğu anlamına gelir.

Üç ek açıklama ayırmak için kullanılır "Katmanlar" uygulamanızda

  • Kontrolörler sadece gönderim, yönlendirme, servis yöntemleri vb.
  • Servis tutma iş mantığı, hesaplamalar vb.
  • Deposu DAO'lardır (Veri Erişim Nesneleri), veritabanına doğrudan erişirler.

Şimdi neden bunları ayırdığını sorabilirsiniz: (AOP-Aspect Yönelimli Programlamayı bildiğinizi varsayalım)

Sadece DAO Katmanının Aktivitesini İzlemek istediğinizi varsayalım. DAO'nuzun her yönteminden önce ve sonra bazı günlüğe kayıt yaptıran bir Aspect (A sınıfı) sınıfı yazacaksınız, bunu üç farklı Katmanınız olduğu ve karıştırılmadığı için AOP kullanarak gerçekleştirebilirsiniz.

Böylece DAO yöntemlerinin "çevresinde", "önce" veya "sonra" olarak günlüğe kaydedilmesini sağlayabilirsiniz. Bunu yapabilirsin çünkü ilk etapta bir DAO vardı. Az önce elde ettiğin şey Endişelerin veya görevlerin ayrılması.

Sadece bir ek açıklama varsa, bu bileşen, tüm karışık, bu yüzden kirli kod!

Yukarıda bahsedilen çok yaygın bir senaryo, neden üç ek not kullanmak için daha fazla kullanım durumları vardır.


333
2018-05-23 05:15



Temel bir sorum var - yay mekanizmasının kullandığı açıklamalar mı yoksa sadece programcının kodun parçalarını ne olduğunu hatırlaması için mi? - user107986
@ user107986 Genellikle Programcı uygulamasında katmanları hatırlamak için vardır. ancak @Respository ayrıca otomatik istisna çeviri özelliği vardır. Bir istisna oluştuğunda olduğu gibi @Repository Bu istisna için genellikle bir işleyici vardır ve DAO sınıfında try catch blokları eklemenize gerek yoktur. PersistenceExceptionTranslationPostProcessor ile birlikte kullanılır - Oliver
Tüm "@Repository" sınıfı için bir Ortak nokta nasıl yazılacağını örnek bir kod yazabilirsiniz. İfadeleri kullanırız ya da fasülye adını kullanırız ama bu tavsiyenin "@Repository" sınıflarında uygulanacağını nasıl söyleyebiliriz. Bunun örneğini almaya çalışıyorum ama bulamıyorum. Yardımınız gerçekten takdir ediliyor. - Moni
Ayrıca, ek açıklamaların tümü şu anda işlevsel olarak aynı olsa da, belirli bir özellik için gelecekte belirli işlevlerin eklenmesi mümkündür. - Cod3Citrus


Baharda @Component, @Service, @Controller, ve @Repository Şunun için kullanılan Stereotype ek açıklamaları şunlardır:

@Controller: nerede senin istek  tanıtım sayfasından eşleme Yani, sunum katmanı doğrudan başka bir dosyaya gitmeyecek @Controller Sınıfı ve istenen yolu denetler @RequestMapping Yöntemden önce yazılan ek açıklama gerekirse.

@Service: Tüm iş mantığı burada, yani Veri ile ilgili hesaplamalar ve hepsi. Kullanıcımızın kalıcılık yöntemini doğrudan aramadığı iş katmanının bu açıklaması, bu açıklamayı kullanarak bu yöntemi çağırır. Kullanıcı isteği doğrultusunda @Repository talep edecektir

@Repository: Bu, veritabanından veri almak için kullanılan uygulamanın Kalıcılık katmanıdır (Veri Erişim Katmanı). diğer bir deyişle Veritabanı ile ilgili tüm işlemler depo tarafından yapılır.

@Component - Diğer bileşenlerinizi (örneğin REST kaynak sınıfları) bir bileşen stereotipiyle not edin.

Açıklamalı bir sınıfın "" olduğunu belirtir.bileşen". Böyle sınıflar   kullanırken otomatik algılama için aday olarak kabul edilir   ek açıklama tabanlı yapılandırma ve sınıf yolu tarama.

Diğer sınıf düzeyi ek açıklamaları, bir   bileşen, tipik olarak özel bir tür bileşen: ör.   @Repository ek açıklaması veya AspectJ'in @Aspect ek açıklaması.

enter image description here


188
2018-03-25 08:00



Bu cevapların hepsi güzel ve her şeyden çok hoşumuza inanıyorum, çoğumuzun istediği şey, hizmet gibi bileşenlerin, "iş mantığı" gibi genel bir tanımdan ziyade daha somut olarak başımıza koyduğumuz özelliklerin bazı kod örnekleridir. bu nesne aksi halde, "oh, bu harika ve her şeyden başka, ancak aynı kodu bile bileşene uygulayabileceğimizi" düşünüyoruz - dtc
Değil herşey iş mantığı hizmetlere girmeli! DDD açısından, hizmetlerin yalnızca birden fazla varlığı etkileyen etki alanı mantığı içermesi gerekir. Cevap gör stackoverflow.com/a/41358034/238134 - deamon
@deamon Evet, ancak geliştiricilerin yaklaşımına bağlıdır - Harshal Patil
@HarshalPatil Tabii ki, hizmetlerdeki tüm iş mantığıyla bir uygulama yazabilirsiniz, ancak bu, anemik bir alan modeline yol açabilir ve bu, varlıklar üzerindeki kısıtları ve tutarlılığı zorlamak için gereksiz yere zorlaştırır. - deamon


İlkbahar 2.5, daha fazla stereotype ek açıklamaları sunar: @Component, @Service and @Controller. @Component, herhangi bir Yaylı yönetilen bileşen için genel bir klişe görevi görür; @Repository, @Service ve @Controller, daha spesifik kullanım durumları için @Component'in uzmanlıkları olarak görev yaparken (örneğin, kalıcılık, servis ve sunum katmanlarında). Bunun anlamı, bileşen sınıflarınızı @Component ile ekleyebilir, ancak bunları @Repository, @Service veya @Controller ile ekleyerek, sınıflarınız araçlarla işlenmek veya yönleriyle ilişkilendirmek için daha uygun olur. Örneğin, bu stereotype ek açıklamaları nokta kesimleri için ideal hedefler oluşturur. Elbette, @Repository, @Service ve @Controller'ın, Spring Framework'ün gelecekteki sürümlerinde ek anlamlar taşıyabilmesi de mümkündür. Bu nedenle, hizmet katmanınız için @Component veya @Service kullanımı arasında bir karar verirseniz, @Service açıkça daha iyi bir seçimdir. Benzer şekilde, yukarıda belirtildiği gibi, @Repository, kalıcılık katmanınızda otomatik istisna çevirisi için bir işaretleyici olarak zaten desteklenmektedir.

@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.

referans :- Spring Documentation - Classpath tarama, Java ile yönetilen bileşenler ve yazma yapılandırmaları  


59
2018-05-15 12:48





@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.  

Hepsini fark edeceksiniz @Repository,@Service veya @Controller açıklamalı @Component. Yani, sadece kullanabilir miyiz @Component otomatik tarama için tüm bileşenler için? Evet, yapabilirsin ve Spring, tüm bileşenlerinizi @Component ek açıklamalı olarak otomatik olarak tarar.

Okumak, iyi bir uygulama değil, okunabilirlik için, her zaman beyan etmelisiniz @Repository,@Service veya @Controller Kodunuzun okunmasını daha kolay hale getirmek için belirli bir katman için.


51
2017-12-16 18:10





Kullanımı @Service ve @Repository ek açıklamalar veritabanı bağlantısı açısından önemlidir.

  1. kullanım @Service tüm web hizmeti türü DB bağlantıları için
  2. kullanım @Repository tüm depolanmış proc DB bağlantılarınız için

Uygun ek açıklamaları kullanmazsanız, geri alma işlemleri ile geçersiz kılınan taahhüt istisnaları ile karşılaşabilirsiniz. Gerilim yükü testi sırasında JDBC işlemlerinin geri alınmasıyla ilgili istisnalar göreceksiniz.


40
2017-11-02 16:05





@Component, @Service ve @Repository Arasındaki Fark

Bu klişeler arasındaki büyük fark, farklı sınıflandırma için kullanılır.

Çok aşamalı bir uygulamada, sunum, servis, iş, veri erişimi gibi farklı katmanlara sahip olacağız. Bir sınıf, Spring tarafından otomatik algılama için açıklanacaksa, aşağıdaki gibi ilgili stereotipi kullanmalıyız.

@Component - jenerik ve uygulama genelinde kullanılabilir.
@Service - Hizmet katmanı düzeyinde sınıflara açıklama ekleyin.
@Repository - Veritabanı deposu olarak davranacak olan kalıcılık katmanındaki sınıflara açıklama eklemek.

Teknik olarak aynı olacaklarsa, neden bunları farklı katman seviyelerinde kullanmalıyız? Neden tüm katmanlarda aynı şeyi kullanmıyorsunuz? Örneğin, kullanırsak @Service tüm katmanlarda, tüm çekirdekler anında ve hiçbir sorunla karşılaşmaz. Küçük bir fark var, örneğin düşünün @Repository.

Postprocessor, tüm istisna çevirmenlerini (PersistenceExceptionTranslator arayüzünün uygulamalarını) otomatik olarak arar ve @Repository Bu şekilde, keşfedilen çevirmenlerin atılan istisnalar üzerine uygun çeviriyi kesip uygulayabilmesi için ek açıklama.

Yukarıdakilere benzer şekilde, gelecekteki Bahar için değer eklemeyi seçebilir @Service, @Controller ve @Repository katmanlama sözleşmelerine göre. Bu ek özellik avantajına göre, sözleşmeye saygı duymak ve bunları katmanlarla uyumlu olarak kullanmak daha iyidir.

Tarama-otomatik algılama, BeanDefinition için bağımlılık enjeksiyon ile ilgili olarak yukarıdakilerin dışında @Component, @Service, @Repository, @Controller aynıdır.


31
2017-10-10 08:11





@Repository  @Hizmet ve @Controller @Component 'i @Component' in yerine yenileyebilir, ancak bu durumda uzmanlığı kaybedersiniz.

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.

24
2017-07-18 11:23