|
|
게시됨 2018. 8. 30. 오후 1:29:41
|
|
|
오늘 동료들과 함께 Spring Boot에서 @Configuration와 @Bean를 조합해 콩을 만들지, 아니면 수업에 @Service 및 기타 주석을 직접 사용할지 논의했습니다. 저자는 대체로 첫 번째 표현, 즉 @Configuration와 @Bean의 조합을 사용합니다.
먼저 예시를 살펴보겠습니다. 목표는 SearchService용 빈을 만드는 것입니다.
@Service 직접 사용하세요:
애플리케이션 시작, 브라우저 접근: http://localhost:8081/search?q=koly, 페이지 표시: ["hello", "koly"]
@Configuration 및 @Bean 활용 방법:
@Service 코드를 직접 사용하는 것과 비교하면, ElasticSearchServiceImpl 위에 @Service 주석을 제거하는 AppConfig 클래스가 있습니다. 한눈에 보면 코드와 클래스가 더 많아요. 그렇다면 후자를 사용하는 이점은 무엇일까요?
저자는 그 이점이 다음과 같다고 믿습니다:
관심사 분리
@Configuration 및 @Bean 방법을 사용하면 콩 생성이 모두 한 곳에서 이루어지며, 인터페이스와 구현은 콩 생성과 아무런 관련이 없습니다.
빈 생성 방식을 변경해야 한다면, 해당 구성 클래스만 보고 수정하면 되며, 해당 Java 빈으로 가서 변경할 필요는 없습니다. 예를 들어, 때로는 빈 생성이 @Scope나 @Profile와 협력해야 하며, 구성 클래스만 수정하면 됩니다.
단독 임무
@service 주석 자체는 두 가지 책임을 가집니다:
하나는 콩 창조입니다;
두 번째는 클래스를 서비스로 식별하는 것입니다.
주석이 달린 클래스가 원래 도메인 주도(Domain-Driven)에서 정의된 "서비스"임을 나타냅니다
설계(Evans, 2003)는 "캡슐화된 상태가 없는 인터페이스로서 모델 내에 독립적으로 존재하는 연산"으로 제시된다.
위는 스프링이 @Service 주석에 대해 설명한 내용입니다. 이 is@Service은 실제로 DDD에서 상태 없는 독립적인 인터페이스 연산을 나타냅니다.
@Bean 및 @Configuration 협력의 방식으로, 빈즈의 생성은 별도의 클래스에 전달되고, 서비스의 정체성은 자바에서 인터페이스와 클래스 이름에 전달됩니다. 이는 Repository와 같은 Spring Data에서도 반영되며, CrudRepository와 같이 이름으로 식별됩니다. 따라서 서비스(Service)는 이름에도 반영되어 있습니다. 특정 계층 정의를 사용하여 Spring에서 제공하는 주석(예: Mapper 레이어, Validator 레이어 등)에 의존하지 않고도 프로젝트 이름에 따라 더 많은 레이어를 제공할 수 있습니다.
게다가 콩과 서비스라는 개념은 2차원적인 개념입니다. 하나는 구체적인 구현에 관한 것이고, 다른 하나는 DDD의 개념에 관한 것입니다.
더 유연해진
@Bean 메서드를 사용하면 라이브러리에서 클래스 인스턴스를 만들 수 있습니다. @Service 메서드를 사용하면 라이브러리 내 해당 클래스에 @Service 주석을 추가할 수 없습니다.
최소한의 지식
최소 지식 원칙은 다음을 의미한다:
기능을 완수하는 데 필요한 기술이나 지식이 적을수록 프로젝트의 단순성을 보장하고 학습의 어려움을 줄여줍니다.
@Service를 사용해 클래스 라이브러리에서 클래스 인스턴스를 생성할 수 없기 때문에, 유사한 요구가 있을 때는 @Configuration 형태와 @Bean 형태를 사용해야 합니다. 이 시점에서는 프로젝트 전체에 @Service, @Configuration, @Bean 같은 주석이 있으며, 이 주석들은 같은 역할을 합니다. 즉, 빈을 만드는 것입니다.
@Service 있으면 @Service, @Component, @Configuration, @Bean가 동시에 발생할 확률이 높습니다.
@Configuration와 @Bean를 사용하면 @Service와 @Component의 사용을 완전히 없앨 수 있는데, 이는 최소 지식 원칙에 부합합니다.
참고로, Summer Beans는 xml로 만들어졌고 이후 Java로 구성이 이루어졌습니다. XML을 사용하지 않는 주된 이유는 XML이 충분히 간결하지 않고 컴파일 시 검사 같은 기능이 없기 때문이며, 빈 생성을 클래스 간에 분산시킬 필요가 없기 때문입니다.
요약하자면, 저자는 @Configuration 및 @Bean 방법을 선호합니다. |
이전의:Python 명령줄에서 화면을 지우는 간단한 방법다음:분산 잠금장치를 사용하는 여러 방법(redis, zookeeper, database)
|
