jobConfiguration 구성 질문

죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.

2장. 작전1: FlatFileItemReader (시스템의 마지막 기록을 읽어내다 ☠️)

작성

안녕하세요, 강의를 보던 중 문득 궁금한 점이 생겨 문의드립니다.

Spring Batch에서 Job 설정 클래스를 구성할 때, 아래와 같이 두 가지 스타일이 혼용되는 것을 자주 보게 되는데요.

🥔 PotatoJobConfiguration (생성자 주입 방식)

@RequiredArgsConstructor
public class PotatoJobConfiguration {

    private final JobRepository jobRepository;
    private final PlatformTransactionManager transactionManager;

    @Bean
    public Job potatoJob() {
        return new JobBuilder("potatoJob", jobRepository)
                .start(potatoStep())
                .build();
    }

    @Bean
    public Step potatoStep() {
        return new StepBuilder("potatoStep", jobRepository)
                .tasklet((contribution, chunkContext) -> RepeatStatus.FINISHED, transactionManager)
                .build();
    }
}

🥬 KimchiJobConfiguration (메서드 파라미터 주입 방식)

@RequiredArgsConstructor
public class KimchiJobConfiguration {

    @Bean
    public Job kimchiJob(
            final JobRepository jobRepository,
            final Step kimchiStep
    ) {
        return new JobBuilder("kimchiJob", jobRepository)
                .start(kimchiStep)
                .build();
    }

    @Bean
    public Step kimchiStep(
            final JobRepository jobRepository,
            final PlatformTransactionManager transactionManager
    ) {
        return new StepBuilder("kimchiStep", jobRepository)
                .tasklet((contribution, chunkContext) -> RepeatStatus.FINISHED, transactionManager)
                .build();
    }
}

강의를 보다 보면 예시마다 사용되는 경우가 다르던데,

어떤 기준에 따라 생성자 주입 방식과 메서드 파라미터 주입 방식을 구분해서 사용하시는지 궁금합니다.

실무에서도 보통 이 둘을 혼용하는 편인지,

아니면 상황에 따라 선호되는 방식이 명확히 나뉘는지 조언 부탁드립니다.

감사합니다.

java spring spring-boot spring-batch backend

답변 2

KILL-9

지식공유자

감자와 김치 조합이라... 

이게 바로 국산 버전 foo, bar인가?

자, 그럼 질문에 답해주마 💀

생성자 주입을 써라 💀

보면 알겠지만 JobRepository와 PlatformTransactionManager는 JobBuilder와 StepBuilder에서 중복으로 사용된다. 따라서 **생성자 주입을 권장한다**.

🚨 긴급 공지사항

우리 강의 예제의 잡 구성 코드를 보면 잡 파라미터 자리에 null을 전달하는 예시를 종종 마주할 것이다.

강의에서 설명했듯이 null을 전달해도 충분하지만, 이 방법은 권장하지 않는다. (학습자 입장에서 null을 전달하는 코드에 혼란을 느낄 수 있을 것이다)

따라서 이런 null 전달 케이스에 대한 수정을 지금 진행하고 있다.

실전 예제: 고구마로 보는 Before/After

ASIS: null 전달 - 혼란스러움

@Bean
public Step sweetPotatoStep() {
    return new StepBuilder("sweetPotatoStep", jobRepository)
        .<SweetPotato, SweetPotato>chunk(10, transactionManager)
        .reader(sweetPotatoItemReader(null))  // 이 null은 무엇인가?
        .writer(sweetPotatoItemWriter())
        .build();
}

@Bean
public FlatFileItemReader<SweetPotato> sweetPotatoItemReader(
        @Value("#{jobParameters['sweetPotatoFile']}") String sweetPotatoFile
) {
    return new FlatFileItemReaderBuilder<SweetPotato>()
        .name("sweetPotatoItemReader")
        .resource(new ClassPathResource(sweetPotatoFile))
        .delimited()
        .names("variety", "sweetness", "weight")
        .targetType(SweetPotato.class)
        .build();
}

TOBE: 의존성 주입 명확히 사용

@Bean
public Step sweetPotatoStep(
    FlatFileItemReader<SweetPotato> sweetPotatoItemReader, // 깔끔하게 주입받음
    ItemWriter<SweetPotato> sweetPotatoItemWriter
) {
    return new StepBuilder("sweetPotatoStep", jobRepository)
        .<SweetPotato, SweetPotato>chunk(10, transactionManager)
        .reader(sweetPotatoItemReader)  // 깔끔하게 전달
        .writer(sweetPotatoItemWriter)
        .build();
}

@Bean
@StepScope
public FlatFileItemReader<SweetPotato> sweetPotatoItemReader(
    @Value("#{jobParameters['sweetPotatoFile']}") String sweetPotatoFile
) {
    return new FlatFileItemReaderBuilder<SweetPotato>()
        .name("sweetPotatoItemReader")
        .resource(new ClassPathResource(sweetPotatoFile))
        .delimited()
        .names("variety", "sweetness", "weight")
        .targetType(SweetPotato.class)
        .build();
}

kill -9 confusion_code
chmod +x clean_injection

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다.
hongdae님, Spring Batch의 Job 설정 클래스 구성 시 두 가지 주입 방식에 대해 질문해 주셨군요. 두 스타일은 각각 장단점이 있으며, 상황에 따라 선택할 수 있습니다.

생성자 주입 방식

명확성: 생성자 주입은 필요한 의존성을 명확히 알 수 있어 가독성을 높여줍니다.
불변성: 초기화 이후 변경이 불가능하기 때문에 객체의 불변성을 보장합니다.
테스트 용이성: 생성자를 통해 의존성을 주입하면 스프링 컨텍스트 없이도 단위 테스트가 가능합니다.

메서드 파라미터 주입 방식

유연성: 필요한 의존성 주입을 메서드 레벨에서 처리할 수 있어 유연한 구성 가능.
코드 간결화: 간단한 설정이 필요한 경우 코드가 더 간결합니다.

상황에 따른 선택

복잡성: 복잡한 Job 설정에서 중요한 의존성은 생성자 주입을 통해 가독성과 유지보수성을 높일 수 있습니다.
단순성 및 편리함: 간단한 설정이고, 외부에서도 유사한 스타일을 주로 사용한다면 메서드 주입으로 일관된 스타일을 유지할 수 있습니다.

실무에서는 팀의 스타일 가이드라인에 따라 혼용될 수 있지만, 주로 특정 스타일로 일관성 있게 사용하는 것이 유지보수에 유리합니다.

비슷한 질문을 다룬 기존의 답변을 참고해 더 많은 인사이트를 얻어보시길 추천드립니다:
- Spring Batch 소스 코드 스타일에 대한 가이드

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변