잡학다식 개발일지

N + 1 문

📌 JPA가 연관된 엔티티를 조회할 때 추가적인 쿼리를 반복적으로 실행하기 때문에 발생하는 문제

• 지연 로딩의 N+1
  • Tutor N : 1 Company 양방향 연관관계

@Entity
@Table(name = "tutor")
public class Tutor {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "company_id")
    private Company company;

    public Tutor() {
    }

    public Tutor(String name) {
        this.name = name;
    }

    public Long getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public void setCompany(Company company) {
        this.company = company;
    }
}

@Entity
@Table(name = "company")
public class Company {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "company")
    private List<Tutor> tutors = new ArrayList<>();

    public Company() {
    }

    public Company(String name) {
        this.name = name;
    }

    public Long getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public List<Tutor> getTutors() {
        return tutors;
    }

}

public class LazyMain {
    public static void main(String[] args) {
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("entity");

        EntityManager em = emf.createEntityManager();

        EntityTransaction transaction = em.getTransaction();

        transaction.begin();

        try {

            Company sparta = new Company("sparta");
            Company etc = new Company("etc");

            em.persist(sparta);
            em.persist(etc);

            Tutor tutor1 = new Tutor("tutor1" );
            Tutor tutor2 = new Tutor("tutor2" );
            Tutor tutor3 = new Tutor("tutor3" );

            tutor1.setCompany(sparta);
            tutor2.setCompany(etc);
            tutor3.setCompany(sparta);

            em.persist(tutor1);
            em.persist(tutor2);
            em.persist(tutor3);

            em.flush();
            em.clear();

            String query = "select t from Tutor t";
            List<Tutor> tutorList = em.createQuery(query, Tutor.class).getResultList();

            for (Tutor tutor : tutorList) {
                System.out.println("tutor.getName() = " + tutor.getName());
                System.out.println("tutor.getCompany().getName() = " + tutor.getCompany().getName());
            }


            transaction.commit();
        } catch (Exception e) {
            transaction.rollback();
        } finally {
            em.close();
        }

        emf.close();
    }
}

• 반복문 1
  1. tutor1~3 조회 및 1차 캐시에 저장
  2. tutor1 출력
  3. sparta 조회 및 1차 캐시에 저장
  4. sparta 출력
• 반복문 2
  1. 1차 캐시의 tutor2 출력
  2. etc 조회 및 1차 캐시에 저장
  3. etc 출력
• 반복문 3
  1. 1차 캐시의 tutor3 출력
  2. 1차 캐시의 sparta 출력
• 튜터(N), 회사(1)가 많아질수록 더 많은 N + 1 문제가 생긴다.

Entity fetch join

📌 JPQL에서 성능 최적화를 위해 fetch join을 제공하며 연관된 엔티티나 컬렉션을 SQL 한번으로 조회할 수 있도록 해주는 기능이다.

• fetch join은 SQL의 JOIN과는 다른 종류이고 객체 그래프를 SQL 한 번에 조회한다. 실무에서 굉장히 많이 활용한다.

• N:1 fetch join(Entity)
  • Tutor N : 1 Comapny 연관관계
  • 일반 JOIN

• fetch join

• 튜터 조회시 연관된 회사도 함께 조회

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;
    private String name;

    @ManyToOne(fetch = FetchType.LAZY)
    private Team team; // 지연 로딩
}

// 사용 시
Member member = entityManager.find(Member.class, 1L);
System.out.println(member.getName()); // 즉시 로드
System.out.println(member.getTeam().getName()); // 이 시점에 Team 데이터를 DB에서 조회

String jpql = "SELECT m FROM Member m JOIN FETCH m.team";
List<Member> members = entityManager.createQuery(jpql, Member.class).getResultList();

for (Member member : members) {
    System.out.println(member.getName()); // 즉시 로드
    System.out.println(member.getTeam().getName()); // Team도 즉시 로드 (프록시 X)
}

Member member = entityManager.find(Member.class, 1L); // Team은 로드되지 않음
System.out.println(member.getTeam().getName()); // 이 시점에 Team을 DB에서 조회

String jpql = "SELECT m FROM Member m JOIN FETCH m.team";
Member member = entityManager.createQuery(jpql, Member.class).getSingleResult();

// 이미 Team이 로드됨
System.out.println(member.getTeam().getName()); // 추가 DB 조회 없음

String jpql = "SELECT m FROM Member m JOIN FETCH m.team";
List<Member> members = entityManager.createQuery(jpql, Member.class).getResultList();

for (Member member : members) {
    System.out.println(entityManager.contains(member)); // true (영속 상태)
    System.out.println(entityManager.contains(member.getTeam())); // true (영속 상태)
}

String jpql = "SELECT m FROM Member m JOIN FETCH m.team";
List<Member> members = entityManager.createQuery(jpql, Member.class).getResultList();

SELECT m.*, t.* 
FROM Member m
JOIN Team t ON m.team_id = t.id;

Collection fetch join

📌 @OneToMany 의 기본 FetchType은 LAZY 이다.

1:N fetch join(Collection)

String query = "select c from Company c join fetch c.tutorList";
List<Company> companyList = em.createQuery(query, Company.class).getResultList();

for (Company company : companyList) {
		System.out.println("company.getName() = " + company.getName());
		System.out.println("company.getTutorList().size() = " + company.getTutorList().size());
}

데이터 중복이 발생하지 않는다.

SQL Query의 조회 결과는 데이터가 중복된다.

Hibernate 6.0 이상 부터는 DISTINCT가 자동으로 적용된다.

JPQL의 DISTINCT

• Database의 DISTINCT 는 완전히 데이터가 같아야 중복이 제거된다.
• JPQL의 DISTINCT 는 같은 PK값을 가진 Entity를 제거한다.

주의점

• Collection 에 fetch join을 사용하면 페이징을 메모리에서 수행한다.
• 코드 예시

String query = "select c from Company c join fetch c.tutorList";
List<Company> companyList = em.createQuery(query, Company.class)
        .setFirstResult(0)
        .setMaxResults(1)
        .getResultList();

• 전체를 조회하는 SQL이 실행된다.
  • setFirstResult(), setMaxResult() 가 SQL에 반영되지 않는다.
• 모든 데이터를 조회하여 메모리에서 페이징을 처리한다.
  • 필요없는 데이터까지 전체 로드한 후 필터링한다.

@BatchSize

📌 JPA에서 N+1 문제를 해결하기 위해 사용되는 설정으로 지연 로딩(Lazy Loading) 시 한 번에 로드할 엔티티의 개수를 조정하여 여러 개의 엔티티를 효율적으로 조회할 수 있다.

String query = "select c from Company c";

List<Company> companyList = em.createQuery(query, Company.class)
        .setFirstResult(0)
        .setMaxResults(2)
        .getResultList();

System.out.println("companyList.size() = " + companyList.size());

for (Company company : companyList) {
    System.out.println("company.getName() = " + company.getName());
    
    for (Tutor tutor : company.getTutorList()) {
        System.out.println("tutor.getName(): " + tutor.getName());
    }
}

1. Company 전체 조회
2. 조회 결과 2개(sparta, etc)에 각각 지연 로딩

@BatchSize

@Entity
@Table(name = "company")
public class Company {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @BatchSize(size = 100)
    @OneToMany(mappedBy = "company")
    private List<Tutor> tutorList = new ArrayList<>();

    public Company() {
    }

    public Company(String name) {
        this.name = name;
    }

    public Long getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public List<Tutor> getTutorList() {
        return tutorList;
    }

}

• 한 번의 IN Query에 식별자(PK)를 조회된 개수만큼 넣어준다.
• 설정 파일의 hibernate.jdbc.batch_size 를 통해 Global 적용이 가능하다.
  • xml, yml, properties 모두 가능

정리

• JPQL의 한계
  1. 동적 쿼리를 사용하기 어렵다.
  2. SQL을 문자열로 작성하여 사용하기 까다롭다.
  3. SQL의 모든 기능을 사용할 수 없다(Native Query 사용).
• fetch join 정리
  1. SQL의 JOIN과 비슷하지만 연관된 엔티티나 컬렉션을 한 번의 쿼리로 함께 로드하는 기능.
     • 지연 로딩 설정된 엔티티도 fetch join으로 사용할 수 있다.
  2. N + 1 문제를 해결할 수 있다.
  3. 데이터의 중복이 발생할 수 있다. (DISTINCT)
  4. 컬렉션 페이징 처리가 힘들다.
     • @BatchSize 적용
  5. 조회 시 여러 테이블이 JOIN 된다면 일반 JOIN을 사용하면 된다.
     • JPQL 또는 QueryDSL로 필요한 데이터만 조회하여 DTO로 반환한다.

@ExceptionHandler

📌 컨트롤러 클래스 내에서 특정 예외를 처리하는 메서드를 정의하는 Annotation으로 예외가 발생했을 때 설정된 메서드가 호출되어 예외를 처리한다.

• 특정 컨트롤러에서 발생한 예외를 처리하기 위한 메서드를 지정한다.
• 단일 컨트롤러 내에서 예외를 처리한다.
• 계층별로 알맞은 예외를 발생(throw new)시키기만 하면된다.

더보기

@RestController
@RequiredArgsConstructor
public class ExceptionHandlerController {

    private final ExceptionHandlerService exceptionHandlerService;

    @RequestMapping("/v1/exception")
    public void illegalArgumentException() {

        throw new IllegalArgumentException("IllegalArgumentException 발생");

    }

    @RequestMapping("/v2/exception")
    public void nullPointerException() {

        throw new NullPointerException("NPE 발생");
    }

    @RequestMapping("/v3/exception")
    public void serviceLayerException() {

        exceptionHandlerService.throwNewIllegalArgumentException();
    }

    // IllegalArgumentException을 처리하는 메서드
    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<Map<String, String>> handleIllegalArgumentException(IllegalArgumentException ex) {

        Map<String, String> response = new HashMap<>();
        response.put("error", ex.getMessage());

        return ResponseEntity
                .status(HttpStatus.BAD_REQUEST)
                .body(response);
    }

}

@RestController
public class NonExceptionHandlerController {

    @RequestMapping("/v4/exception")
    public void illegalArgumentException() {

        throw new IllegalArgumentException("IllegalArgumentException 발생");

    }

}

@Service
public class ExceptionHandlerService {

    public void throwNewIllegalArgumentException() {
        throw new IllegalArgumentException("ServiceLayer Exception");
    }

}

 

• 문제점
  1. Controller 코드에 Exception 처리를 위한 책임이 추가된다.(단일 책임 원칙 위반)
  2. 단일 컨트롤러 내의 예외만 처리가 가능하다.(컨트롤러 예외처리 중복코드)
  3. 코드 재사용, 유지보수성 부족

@ControllerAdvice

📌 @ControllerAdvice와 동일한 기능을 제공하지만 @RestController를 포함하고 있어 반환 값이 자동으로 JSON 형태로 변환되며 REST API에서 발생하는 예외를 처리할 때 사용한다.

• Application 전역에서 발생한 예외를 처리한다.

• @RestControllerAdvice
  • REST API의 예외를 처리한다.
  • 반환 값이 JSON이다.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<Map<String, String>> handleIllegalArgumentException(IllegalArgumentException ex) {

        Map<String, String> response = new HashMap<>();
        response.put("error", ex.getMessage());

        return ResponseEntity
                .status(HttpStatus.BAD_REQUEST)
                .body(response);
    }

}

• @ExceptionHandler 이 선언되지 않은 컨트롤러의 예외처리 가능

Formatter

📌 주로 사용자 지정 포맷을 적용해 데이터 변환을 처리할 때 사용된다. Formatter는 ConversionService와 비슷한 목적을 가지지만 문자열을 객체로 변환하거나 객체를 문자열로 변환하는 과정에서 포맷팅을 세밀하게 제어할 수 있다.

• 객체를 특정한 포맷에 맞춰서 문자로 출력하는 기능에 특화된것이 Fomatter이다.
• Converter보다 조금 더 세부적인 기능이라고 생각하면 된다.

public interface Formatter<T> {
    String print(T object, Locale locale);   // 객체 → 문자열 (포맷팅)
    T parse(String text, Locale locale) throws ParseException; // 문자열 → 객체 (역변환)
}

public class LocalDateFormatter implements Formatter<LocalDate> {

    @Override
    public LocalDate parse(String text, Locale locale) throws ParseException {
        return LocalDate.parse(text, DateTimeFormatter.ofPattern("yyyy-MM-dd"));
    }

    @Override
    public String print(LocalDate object, Locale locale) {
        return object.format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));
    }
}

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addFormatter(new LocalDateFormatter());
    }
}

@GetMapping("/date")
public String getDate(@RequestParam LocalDate date) {
    return "Formatted Date: " + date.toString();
}

GET /date?date=2023-12-25

public interface Converter<S, T> {
    T convert(S source); // 소스 타입 → 대상 타입
}

public class StringToIntegerConverter implements Converter<String, Integer> {

    @Override
    public Integer convert(String source) {
        return Integer.valueOf(source);
    }
}

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addConverter(new StringToIntegerConverter());
    }
}

@GetMapping("/number")
public String getNumber(@RequestParam Integer number) {
    return "Number: " + number;
}

GET /number?number=123

• Locale
  • 지역 및 언어 정보를 나타내는 객체.
    • 언어코드 en, ko
    • 국가코드 US, KR
  • 특정 지역 및 언어에 대한 정보를 제공하여 국제화 및 지역화 기능을 지원한다.
  • 국제화
    • Locale 정보에 따라서 한글을 보여줄지 영문을 보여줄지 선택할 수 있다.

Formatter Interface

• Printer, Parser 상속
• 객체를 문자로 변환하고 문자를 객체로 변환하는 두가지 기능을 모두 가지고 있다.
• Printer

Object를 String으로 변환한다.

Parser

String을 Object로 변환한다.

Formatter 적용

@Slf4j
public class PriceFormatter implements Formatter<Number> {
	
	@Override
  public Number parse(String text, Locale locale) throws ParseException {
    log.info("text = {}, locale={}", text, locale);
		
		// 변환 로직
		// NumberFormat이 제공하는 기능
		NumberFormat format = NumberFormat.getInstance(locale);
		// "10,000" -> 10000L
		return format.parse(text);
  }

  @Override
  public String print(Number object, Locale locale) {
			log.info("object = {}, locale = {}", object, locale);
			// 10000L -> "10,000"
      return NumberFormat.getInstance(locale).format(object);
  }
	
}

Number

• Integer, Long, Double 등의 부모 클래스

class PriceFormatterTest {

		PriceFormatter formatter = new PriceFormatter();

    @Test
    void parse() throws ParseException {
        // given, when
        Number result = formatter.parse("1,000", Locale.KOREA);

        // then
        // parse 결과는 Long
        Assertions.assertThat(result).isEqualTo(1000L);
    }

    @Test
    void print() {
        // given, when
        String result = formatter.print(1000, Locale.KOREA);

        // then
        Assertions.assertThat(result).isEqualTo("1,000");
    }
}

Spring Formatter

📌 Spring의 Formatter는 문자열 데이터를 특정 객체로 변환하거나, 객체를 특정 문자열 형식으로 변환(포맷팅)하는 데 사용되는 인터페이스입니다. 데이터 포맷팅과 역변환을 쉽게 처리할 수 있도록 Spring에서 제공됩니다

FormattingConversionService

📌 ConversionService와 Formatter를 결합한 구현체로 타입 변환과 포맷팅이 필요한 모든 작업을 한 곳에서 수행할 수 있도록 설계되어 있어서 다양한 타입의 변환과 포맷팅을 쉽게 적용할 수 있다.

• 어댑터 패턴을 사용하여 Formatter가 Converter처럼 동작하도록 만들어준다.

DefaultFormattingConversionService

📌 FormattingConversionService + 통화, 숫자관련 Formatter를 추가한것

public class FormattingConversionServiceTest {

    @Test
    void formattingConversionService() {

        // given
        DefaultFormattingConversionService conversionService = new DefaultFormattingConversionService();

        // Converter 등록
        conversionService.addConverter(new StringToPersonConverter());
        conversionService.addConverter(new PersonToStringConverter());
        // Formatter 등록
        conversionService.addFormatter(new PriceFormatter());

        // when
        String result = conversionService.convert(10000, String.class);

        // then
        Assertions.assertThat(result).isEqualTo("10,000");

    }

}

• ConversionService가 제공하는 convert()를 사용하면 된다.

SpringBoot의 기능

📌 SpringBoot는 기본적으로 WebConversionService를 사용한다.

• DefaultFormattingConversionService 상속

Spring이 제공하는 Formatter

📌 Spring은 어노테이션 기반으로 원하는 형식의 Formatter를 사용할 수 있도록 기능을 제공한다.

• Annotation
  • DTO 필드들에 적용 가능
  1. @NumberFormat
     • 숫자 관련 지정 Formatter 사용
     • NumberFormatAnnotationFormatterFactory
  2. @DateTimeFormat
     • 날짜 관련 지정 Formatter 사용
     • Jsr310DateTimeFormatAnnotationFormatterFactory

TypeConverter

📌 Spring에서 객체의 타입을 서로 변환하는 데 사용되는 인터페이스로 Spring의 데이터 바인딩 과정에서 문자열을 특정 객체로 변환하거나 하나의 객체 타입을 다른 타입으로 변환할 때 사용한다.

• 문자를 숫자로, 숫자를 문자로 변환하는 등 Web Application을 만들다보면 Type을 변환해야 하는 경우가 많이 발생한다.

• 결론
  1. 요청 파라미터로 전달하는 10 값은 실제로는 문자열(String) 10이다.
  2. @RequestParam을 사용하면 문자 10을 Integer 타입의 숫자 10으로 변환된다.
  3. @ModelAttribute, @PathVariable 에서도 타입 변환을 확인할 수 있다.
  • Spring 내부에서 누군가가 타입을 자동으로 변환한다.

Converter Interface

• Spring이 제공하는 인터페이스
  • implements하여 Converter로 등록하면 된다.
• Converter는 모든 타입(T)에 적용할 수 있다.
• 개발자가 새로운 Type을 만들어서 사용할 수 있도록 만든다.
  • 변환하고자 하는 타입에 맞춰서 Type Converter를 구현하고 등록하면 된다.

Converter

📌 데이터 타입 간 변환을 처리하는 인터페이스 , 주로 웹 요청 파라미터를 Java 객체로 변환하거나 그 반대로 변환할 때 사용되며 커스텀 변환 로직을 정의할 수 있다.

• 주의점
  • org.springframework.core.convert.converter
  • Spring의 Converter와 같은 이름을 가진 Interface가 많으니 주의해야 한다.

• 코드 예시
  • String → Integer
  • Converter<S, T> 에서 S는 변환할 Source T는 변환할 Type으로 설정하면 된다.

@Slf4j
public class StringToIntegerConverter implements Converter<String, Integer> {
	
	@Override
	public Integer convert(String source) {
		log.info("source = {}", source);
		// 검증
		return Integer.valueOf(source);
	}
	
}

• 파라미터로 들어온 source가 Interger로 변환된다.
• Integer → String

@Slf4j
public class IntegerToStringConverter implements Converter<Integer, String> {
	
	@Override
	public String convert(Integer source) {
		log.info("source = {}", source);
		return String.valueOf(source);
	}
}

• 파라미터로 들어온 source가 String으로 변환된다.
• String → Person

@Getter
public class Person {
	
		// 이름
		private String name;
		// 나이
		private int age;
	
		public Person(String name, int age) {
			this.name = name;
			this.age = age;
		}
	
}

• 요청 예시
  • localhost:8080/type-converter?person=wonuk:1200

public class StringToPersonConverter implements Converter<String, Person> {
		// source = "wonuk:1200"
		@Override
		public Person convert(String source) {
			// ':' 를 구분자로 나누어 배열로 만든다.
			String[] parts = source.split(":");
	
			// 첫번째 배열은 이름이다. -> wonuk
	    String name = parts[0];
	    // 두번째 배열은 개월수이다. -> 1200
	    int months = Integer.parseInt(parts[1]);
	    
			// 개월수 나누기 12로 나이를 구하는 로직 (12개월 단위만 고려)
			int age = months / 12;
	
			return new Person(name, age);
		}
}

public class PersonToStringConverter implements Converter<Person, String> {
		
		@Override
		public String convert(Person source) {
				// 이름
				String name = source.getName();
				// 개월수
				int months = source.getAge * 12;
				// "wonuk:1200"
				return name + ":" + months;
		}
	
}

• TypeConverter 사용
  • 구현은 단순하게 직접 메서드를 구현하여 모듈화 하면된다.
  • TypeConverter 를 생성하여 직접 사용하면 컨트롤러에서 변환하는 방식과 큰 차이가 없다.

PersonToStringConverter converter = new PersonToStringConverter();
String source = "wonuk:1200";
converter.convert(source);

• Converter를 편리하게 등록하고 사용할 수 있도록 만들어주는 기능이 필요하다.
• Spring은 String, Integer, Enum등 자주 사용되는 타입에 대한 컨버터를 제공하고 사용할 수 있도록 등록되어 있다.

Spring의 다양한 Converter

📌 Spring에서 제공하는 다양한 Converter 인터페이스가 존재하며 이들은 Spring의 데이터 바인딩, 요청/응답 처리, 속성 값 주입 등에 사용되고 ConversionService를 통해 등록 및 관리된다.

1. Converter
   • 기본적인 변환을 담당하는 인터페이스
   • 단일 타입에서 단일 타입으로 변환할 때 사용한다.
     • Converter<Source, Type>
2. ConverterFactory
   • 클래스 계층 구조가 복잡한 경우 사용
   • 기본 타입과 다양한 서브 타입 간의 변환을 지원한다.
3. GenericConverter
   • 다양한 타입 간의 유연한 변환을 지원한다.
   • 복잡한 타입 변환 로직을 구현할 때 유리하다.
4. ConditionalGenericConverter
   • GenericConverter 의 확장형으로 특정 조건에서만 타입 변환을 수행한다.
   • 추가적으로 matches() 를 통해 변환 가능 여부를 판단할 수 있다.

ConversionService

📌 Spring은 Converter를 모아서 편리하게 관리하고 사용할 수 있게 해주는 기능을 제공한다. 이것이 Conversion Service 이다.

ConversionService 인터페이스

1. canConvert()
   • Convert 가능 여부를 확인하는 기능
2. convert()
   • 실제 변환하는 기능

DefaultConversionService

📌 Spring의 표준 ConversionService로 기본 제공 Converter와 확장 가능성을 통해 다양한 타입 변환을 유연하게 처리할 수 있도록 지원한다.

• DefaultConversionService
  • ConversionService를 구현한 구현체

ConvertRegistry에 다양한 Converter를 등록한다.

• ConverterRegistry
  • Converter를 등록하고 관리하는 기능을 제공한다.

import static org.assertj.core.api.Assertions.*;

public class ConversionServiceTest {

    @Test
    void defaultConversionService() {
        // given
        DefaultConversionService dcs = new DefaultConversionService();
        dcs.addConverter(new StringToPersonConverter());
        Person wonuk = new Person("wonuk", 100);
        
				// when
        Person stringToPerson = dcs.convert("wonuk:1200", Person.class);
        
				// then
        assertThat(stringToPerson.getName()).isEqualTo(wonuk.getName());
        assertThat(stringToPerson.getAge()).isEqualTo(wonuk.getAge());
    }

}

• 컨버터를 사용할 때는 종류를 몰라도된다.
• 컨버터는 ConversionService 내부에서 숨겨진채 제공된다.
  • 반환 타입, 파라미터 타입, 제네릭 등으로 ConversionService가 컨버터를 찾는다.
• 즉, 클라이언트는 ConversionService 인터페이스만 의존하면 된다.
  • 컨버터 등록과 사용의 분리

ISP(인터페이스 분리 원칙, Interface Segregation Principal)

📌 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 분리하는 원칙

• DefaultConversionService
  1. ConversionRegistry : 컨버터 등록
  2. ConversionService ****: ****컨버터 사용
• 인터페이스를 분리하면 컨버터를 사용하는 클라이언트는 필요한 메서드만 알면된다.
• ConversionRegistry 가 변경되어도 ConversionService와 연관이 없다.
• Spring은 내부적으로 위와같이 등록, 사용이 분리된 인터페이스들이 아주 많다.

Converter 요약

Spring의 **Converter**는 데이터 타입 간 변환을 처리하는 인터페이스입니다. 주로 Spring의 데이터 바인딩 또는 사용자 정의 변환 작업에 사용됩니다. 간단한 입력 값 변환에서부터 복잡한 객체 변환까지 유연하게 지원합니다.

Converter의 주요 특징

1. 데이터 타입 변환:
   • 소스 타입(Source Type)에서 대상 타입(Target Type)으로 변환.
   • 예: String → Integer, String → LocalDate.
2. 간결한 인터페이스:
   • 구현이 간단하며 특정 변환 작업에 집중.
3. 범용 사용 가능:
   • Spring의 데이터 바인딩, 요청 파라미터 변환, 커스텀 변환 로직 등에 사용.
4. 확장 가능:
   • Spring이 기본으로 제공하는 변환기 외에도 사용자 정의 변환기를 구현할 수 있음.

Converter 인터페이스

public interface Converter<S, T> {
    T convert(S source);
}

• S: 소스 데이터 타입 (변환 전 데이터 타입).
• T: 대상 데이터 타입 (변환 후 데이터 타입).

Converter의 사용 사례

1. 문자열을 날짜로 변환 (String → LocalDate)

public class StringToLocalDateConverter implements Converter<String, LocalDate> {

    @Override
    public LocalDate convert(String source) {
        // 문자열을 LocalDate로 변환
        return LocalDate.parse(source, DateTimeFormatter.ISO_DATE);
    }
}

Spring에서 Converter 등록

Spring에서는 변환기를 전역적으로 등록하거나, 특정 컨텍스트에서 사용할 수 있습니다.

1. 전역 등록

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        // 커스텀 Converter 등록
        registry.addConverter(new StringToLocalDateConverter());
    }
}

Spring의 기본 Converter

Spring은 이미 다양한 기본 변환기를 제공합니다:

• Primitive 타입 변환: String → int, String → double 등.
• Java 날짜/시간 변환: String → LocalDate, String → LocalDateTime.
• Enum 변환: String → Enum.

Converter와 일상적인 비유

비유: 데이터를 변환하는 "도구 상자"

• Converter는 한 가지 타입의 데이터를 다른 타입으로 변환하는 간단한 도구입니다.
• 예를 들어, 숫자 데이터를 텍스트로 변환하는 계산기처럼, Converter는 입력 값을 원하는 형태로 만들어줍니다.

Converter 사용 예제

컨트롤러에서 사용

@RestController
@RequestMapping("/api")
public class ExampleController {

    @GetMapping("/date")
    public String getDate(@RequestParam String date, Converter<String, LocalDate> converter) {
        LocalDate localDate = converter.convert(date);
        return "Converted date: " + localDate.toString();
    }
}

요청 예

GET /api/date?date=2023-12-25

결과

Converted date: 2023-12-25

Converter와 관련된 확장

1. Formatter:
   • Converter의 확장형으로, 데이터를 특정 형식(포맷)으로 변환하고 역변환도 지원.
   • 예: 날짜를 특정 형식으로 변환하거나 파싱.
2. GenericConverter:
   • 보다 범용적인 변환을 지원하는 고급 형태의 Converter.
3. ConversionService:
   • 여러 변환기를 한데 모아 관리하고, 필요한 변환기를 자동으로 찾아주는 Spring의 변환 관리 서비스.

Converter와 HttpMessageConverter의 차이

• Converter:
  • 데이터 타입 간 변환.
  • String → Integer, String → LocalDate 등 간단한 데이터 변환에 초점.
• HttpMessageConverter:
  • HTTP 요청/응답 데이터를 변환.
  • JSON → Java 객체, Java 객체 → JSON 등, 네트워크 통신에 초점.

결론

Spring의 Converter는 데이터 타입을 변환하는 단순하고 강력한 도구입니다. 데이터를 변환하는 간단한 작업부터, 프로젝트 전반에서 데이터 바인딩에 활용됩니다.

비유: 필요한 데이터를 원하는 형태로 "가공"하는 변환기입니다.

HttpMessageConverter

📌 클라이언트와 서버 간의 HTTP 요청과 응답을 처리할 때 데이터 형식 변환을 담당 한다. 클라이언트가 보낸 데이터를 서버가 이해할 수 있는 형태로 변환하거나, 서버가 응답으로 보내는 데이터를 클라이언트가 이해할 수 있는 형태로 변환할 때 사용됩니다. [ View를 응답하는 것이 아닌, Rest API(HTTP API)로 JSON, TEXT, XML 등의 데이터를 응답 Message Body에 직접 입력하는 경우 HttpMessageConverter를 사용한다. ]

• 1. SSR → @Controller + View Template → 서버 측에서 화면을 동적으로 그린다.
• 2. CSR → @RestController + Data → 클라이언트 측에서 화면을 동적으로 그린다.
• 3. 실제로는 두가지 기술이 함께 사용되는 경우가 많다.

• HTTP 응답 메세지 Body에 데이터를 직접 입력 후 반환한다.
• 요청 Accept Header + Controller 반환 타입

ViewResolver가 아닌 HttpMessageConverter가 동작한다.

• HttpMessageConverter가 적용되는 경우
  1. HTTP 요청 : @RequestBody, HttpEntity<>, RequestEntity<>
  2. HTTP 응답 : @ResponseBody, HttpEntity<>, ResponseEntity<>
  • HttpMessageConverter는 요청과 응답 모두 사용된다.

우선순위

📌 Spring은 다양한 HttpMessageConverter를 제공하고 있고 우선순위가 있다. 대상 Class와 MediaType을 체크해서 어떤 Converter를 사용할지 결정한다.

동작 순서와 예시

요청 데이터 읽기

@RestController

@PostMapping(value = "/example", produces = "application/json")

public ResponseDto example(@RequestBody RequestDto dto)

ResponseDto responseDto = service.example(dto);

return responseDto;

boolean canWrite(Class<?> clazz, @Nullable MediaType mediaType);

@Override
public boolean canWrite(Class<?> clazz, @Nullable MediaType mediaType) {
    // JSON 컨버터는 기본적으로 모든 객체 타입을 지원
    if (mediaType == null || mediaType.isCompatibleWith(MediaType.APPLICATION_JSON)) {
        return true; // JSON 형식으로 변환 가능
    }
    return false; // JSON 외 미디어 타입은 변환 불가
}

GET /api/example HTTP/1.1
Accept: application/json

void write(
    T t,
    @Nullable MediaType contentType,
    HttpOutputMessage outputMessage
) throws IOException, HttpMessageNotWritableException;

@Override
public void write(
    Object t,
    @Nullable MediaType contentType,
    HttpOutputMessage outputMessage
) throws IOException {
    // 1. JSON 변환기 초기화 (예: ObjectMapper 사용)
    ObjectMapper objectMapper = new ObjectMapper();

    // 2. Content-Type 설정
    if (contentType != null) {
        outputMessage.getHeaders().setContentType(contentType);
    } else {
        outputMessage.getHeaders().setContentType(MediaType.APPLICATION_JSON);
    }

    // 3. 객체를 JSON으로 변환하여 OutputStream에 쓰기
    OutputStream bodyStream = outputMessage.getBody();
    objectMapper.writeValue(bodyStream, t);

    // 4. OutputStream 닫기 (Spring이 자동으로 관리)
}

GET /example HTTP/1.1
Accept: application/json

@GetMapping("/example")
public ResponseDto example() {
    return new ResponseDto("success", "Operation completed");
}

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 58

{"status":"success","message":"Operation completed"}

응답 데이터 쓰기

HttpMessageConverter 구조

📌 HttpMessageConverter를 주로 사용하는 어노테이션 @RequestBody, @ResponseBody

• 요청시에는 Argument Resolver가 사용하는것이다.
• 응답시에는 ReturnValueHandler가 사용한다.

대표적인 ArgumentResolver, ReturnValueHandler

1. ArgumentResolver

**ArgumentResolver**는 컨트롤러 메서드 파라미터에 요청 데이터를 바인딩하는 역할을 합니다.

대표적인 ArgumentResolver

Resolver 이름 설명

ArgumentResolver의 예제

@RequestParam과 @RequestBody 사용

@GetMapping("/greet")
public String greetUser(@RequestParam String name) {
    return "Hello, " + name;
}

@PostMapping("/process")
public String processData(@RequestBody MyDto data) {
    return "Processed: " + data.getValue();
}

• RequestParamMethodArgumentResolver: name 값을 쿼리 파라미터에서 추출.
• RequestBodyArgumentResolver: 요청 본문(JSON)을 MyDto 객체로 변환.

2. ReturnValueHandler

**ReturnValueHandler**는 컨트롤러 메서드가 반환한 데이터를 클라이언트에게 적절히 변환하여 응답으로 전달합니다.

대표적인 ReturnValueHandler

Handler 이름 설명

ReturnValueHandler의 예제

@ResponseBody와 ResponseEntity 사용

@RestController
public class ExampleController {

    @GetMapping("/json")
    public MyDto getJson() {
        return new MyDto("data", 123); // RequestResponseBodyMethodProcessor 처리
    }

    @GetMapping("/response")
    public ResponseEntity<String> getResponse() {
        return ResponseEntity.ok("OK"); // HttpEntityMethodProcessor 처리
    }
}

• RequestResponseBodyMethodProcessor:
  • MyDto 객체를 JSON 형식으로 변환하여 응답 본문에 작성.
• HttpEntityMethodProcessor:
  • ResponseEntity의 상태 코드, 헤더, 본문을 설정하여 응답.

전체 흐름 정리

Spring MVC의 요청 처리 과정에서 **ArgumentResolver**와 **ReturnValueHandler**는 다음처럼 동작합니다:

1. ArgumentResolver:
   • 클라이언트 요청 데이터를 컨트롤러 메서드 파라미터에 맞게 변환.
   • 예: 쿼리 파라미터 → @RequestParam, 본문(JSON) → @RequestBody.
2. ReturnValueHandler:
   • 컨트롤러 메서드의 반환값을 클라이언트 응답으로 변환.
   • 예: 객체 → JSON, 문자열 → 뷰 이름 해석.

예제 통합

@RestController
public class ExampleController {

    @PostMapping("/submit")
    public ResponseEntity<String> submit(@RequestBody MyDto dto) {
        // ArgumentResolver: RequestBodyArgumentResolver 처리
        System.out.println("Received: " + dto.getValue());
        return ResponseEntity.ok("Processed successfully"); // ReturnValueHandler: HttpEntityMethodProcessor 처리
    }
}

요청:

POST /submit
Content-Type: application/json

{
    "value": "example"
}

응답:

HTTP/1.1 200 OK
Content-Type: text/plain

Processed successfully

이렇게 Spring MVC는 ArgumentResolver로 요청 데이터를 바인딩하고, ReturnValueHandler로 응답 데이터를 변환합니다!

요청과 응답

📌 ArgumentResolver와 HttpMessageConverter는 다르다.

WebMvcConfigurer

📌 Spring MVC의 설정을 사용자 정의할 수 있도록 제공되는 인터페이스로 implements하여 설정을 확장하거나 커스터마이징할 수 있다.

• 주요 인터페이스
  1. HandlerMethodArgumentResolver
  2. HandlerMethodReturnValueHandler
  3. HttpMessageConverter
  • 모두 인터페이스로 구현되어 있으며 대부분 구현되어 있다.
    • Spring에서 기본적으로 제공하고 있다.
  • 개발자는 잘 사용하면 된다.

• 기능의 확장
  • WebMvcConfigurer를 상속받고 Spring Bean으로 등록

public interface WebMvcConfigurer {
    default void configurePathMatch(PathMatchConfigurer configurer) {
    }

    default void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
    }

    default void configureAsyncSupport(AsyncSupportConfigurer configurer) {
    }

    default void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
    }

    default void addFormatters(FormatterRegistry registry) {
    }

    default void addInterceptors(InterceptorRegistry registry) {
    }

    default void addResourceHandlers(ResourceHandlerRegistry registry) {
    }

    default void addCorsMappings(CorsRegistry registry) {
    }

    default void addViewControllers(ViewControllerRegistry registry) {
    }

    default void configureViewResolvers(ViewResolverRegistry registry) {
    }

    default void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
    }

    default void addReturnValueHandlers(List<HandlerMethodReturnValueHandler> handlers) {
    }

    default void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
    }

    default void extendMessageConverters(List<HttpMessageConverter<?>> converters) {
    }

    default void configureHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
    }

    default void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
    }

    @Nullable
    default Validator getValidator() {
        return null;
    }

    @Nullable
    default MessageCodesResolver getMessageCodesResolver() {
        return null;
    }
}

1. addArgumentResolvers()
2. addReturnValueHandlers()
3. extendMessageConverters()

• 필요한 메서드를 오버라이딩 하면된다.

• @Configuration
  • @Component 를 포함하고 있다. (Spring Bean 등록이 된다.)

HttpMessageConverter 요약

HttpMessageConverter는 Spring MVC에서 클라이언트와 서버 간 데이터를 변환하는 데 사용되는 컴포넌트입니다. HTTP 요청과 응답의 본문을 Java 객체와 JSON, XML, TEXT 등으로 상호 변환합니다.

HttpMessageConverter의 역할

1. 요청 처리:
   • 클라이언트가 JSON, XML 등 형식으로 요청 본문을 보내면 이를 Java 객체로 변환.
2. 응답 생성:
   • 컨트롤러가 반환한 Java 객체를 JSON, XML, TEXT 등으로 변환하여 클라이언트로 전송.

일상적인 비유

• 비유: 번역가(Translator)
  • 한 사람이 영어로 말을 하고, 다른 사람이 한국어로 이해하려면 번역가가 필요합니다.
  • 여기서 영어는 JSON, XML 등의 데이터 형식이고, 한국어는 Java 객체입니다.
  • 번역가(HttpMessageConverter)가 데이터를 양쪽에서 서로 이해할 수 있도록 변환합니다.

HttpMessageConverter의 동작 흐름

1. 클라이언트 요청:
   • 클라이언트가 JSON 요청을 보냅니다.
   • 예: {"name": "John", "age": 30}
2. 요청 데이터 변환:
   • HttpMessageConverter가 JSON 데이터를 Java 객체로 변환.
3. 컨트롤러 처리:
   • 컨트롤러 메서드에서 비즈니스 로직 처리.
4. 응답 데이터 변환:
   • 컨트롤러 메서드가 반환한 Java 객체를 JSON 형식으로 변환하여 클라이언트에 응답.

대표적인 HttpMessageConverter 구현체

Converter 이름 역할

HttpMessageConverter 사용 예제

요청 본문(JSON) → Java 객체 (@RequestBody)

@RestController
@RequestMapping("/api/users")
public class UserController {

    @PostMapping
    public String createUser(@RequestBody UserDto userDto) {
        return "User created: " + userDto.getName();
    }
}

1. 클라이언트 요청:
2. POST /api/users Content-Type: application/json { "name": "John", "age": 30 }
3. HttpMessageConverter 동작:
   • MappingJackson2HttpMessageConverter가 JSON 데이터를 UserDto 객체로 변환.
   • 컨트롤러는 변환된 UserDto 객체를 사용.
4. 컨트롤러 결과:
   • User created: John

Java 객체 → JSON 응답 (@ResponseBody)

@RestController
public class ExampleController {

    @GetMapping("/user/{id}")
    public UserDto getUser(@PathVariable Long id) {
        return new UserDto(id, "John", 30); // Java 객체 반환
    }
}

1. 클라이언트 요청:
2. GET /user/1 Accept: application/json
3. HttpMessageConverter 동작:
   • 컨트롤러에서 반환한 UserDto 객체를 MappingJackson2HttpMessageConverter가 JSON으로 변환.
4. 클라이언트 응답:
5. HTTP/1.1 200 OK Content-Type: application/json { "id": 1, "name": "John", "age": 30 }

HttpMessageConverter의 장점

1. 자동 변환:
   • JSON, XML, TEXT 등 다양한 데이터 형식을 Java 객체로 쉽게 변환 가능.
   • 개발자가 수동으로 데이터 변환 코드를 작성할 필요 없음.
2. 확장 가능:
   • 필요에 따라 커스텀 HttpMessageConverter를 작성해 특별한 데이터 형식을 처리 가능.
3. REST API 친화적:
   • RESTful 서비스를 개발할 때 요청과 응답 데이터를 간단하게 처리.

커스텀 HttpMessageConverter

Spring MVC에서 특정 데이터 포맷을 처리하기 위해 커스텀 HttpMessageConverter를 구현할 수 있습니다.

예제: CSV 데이터를 처리하는 HttpMessageConverter

1. 커스텀 HttpMessageConverter 구현:
2. public class CsvHttpMessageConverter extends AbstractHttpMessageConverter<MyCsvDto> { public CsvHttpMessageConverter() { super(new MediaType("text", "csv")); } @Override protected boolean supports(Class<?> clazz) { return MyCsvDto.class.isAssignableFrom(clazz); } @Override protected MyCsvDto readInternal(Class<? extends MyCsvDto> clazz, HttpInputMessage inputMessage) throws IOException { // CSV 데이터를 Java 객체로 변환하는 로직 return new MyCsvDto("example", 123); } @Override protected void writeInternal(MyCsvDto myCsvDto, HttpOutputMessage outputMessage) throws IOException { // Java 객체를 CSV 데이터로 변환하는 로직 String csv = myCsvDto.getName() + "," + myCsvDto.getValue(); outputMessage.getBody().write(csv.getBytes()); } }
3. Spring에 등록:
4. @Configuration public class WebConfig implements WebMvcConfigurer { @Override public void extendMessageConverters(List<HttpMessageConverter<?>> converters) { converters.add(new CsvHttpMessageConverter()); } }

결론

HttpMessageConverter는 클라이언트와 서버 간 데이터 변환을 자동화하여 개발자의 작업을 간소화합니다. 데이터를 JSON, XML 등 다양한 포맷으로 처리할 수 있으며, 필요에 따라 커스터마이징하여 확장할 수도 있습니다.

비유: 데이터를 주고받는 번역가로, 클라이언트와 서버가 서로 다른 언어(JSON, XML, Java 객체 등)를 이해할 수 있게 해주는 역할을 합니다.

RequestMappingHandlerAdapter

📌 Spring MVC에서 HTTP 요청을 컨트롤러 메서드에 매핑하고 실행하는 핵심 구성 요소로, 클라이언트 요청을 적절한 컨트롤러 메서드와 연결한 후 이 메서드를 호출하여 결과를 반환하는 역할을 수행한다.

Spring MVC 구조

• 요청 데이터가 변환이된다.(HttpMessageConverter)
• 요청이 Controller에 전달되는 HandlerAdapter와 Handler 사이에서 어떤 일이 일어난다!

RequestMappingHandlerAdapter

@RequestMapping 을 처리하는 HandlerAdapter의 구현체

@PostMapping , @GetMapping, @PutMapping, @PatchMapping, @DeleteMapping 등은 모두 @RequestMapping의 일종이다.

ArgumentResolver

• RequestMappingHandlerAdapter는 ArgumentResolver를 호출하여 Controller가 필요한 다양한 파라미터의 값을 생성한다.
• HttpServletRequest, Model, HttpEntity,@ModelAttribute, @RequestBody, @RequestParam 등 다양한 파라미터 바인딩을 할 수 있는 이유이다.
• ArgumentResolver를 통하여 값이 준비되면 해당값을 가지고 실제 Controller를 호출한다.
• 어노테이션도 매핑 및 바인딩이 필요했다...

ArgumentResolver

📌 Spring MVC에서 컨트롤러 메서드의 파라미터를 자동으로 바인딩하는 역할을 하는 인터페이스로 요청이 컨트롤러 메서드에 전달될 때 각 파라미터를 적절한 객체로 변환하여 주입하는 것을 담당한다.

ArgumentResolver 종류

• Spring은 다양한 Argument Resolver들을 기본적으로 제공한다.
  1. RequestBodyArgumentResolver(@RequestBody)

            2. RequestHeaderArgumentResolver(@RequestHeader)

HandlerMethodArgumentResolver

• ArgumentResolver의 실제 이름
  • 인터페이스로 구성되어 있다.
  • implements 하여 커스텀하게 파라미터를 만들 수 있다.(확장)
• supportsParameter(MethodParameter parameter);
  • 컨트롤러가 필요로하는 메서드의 파라미터를 지원하는지 여부를 검사한다.
• 지원한다면 resolveArgument() 메서드를 통해 Object(객체)로 만들어준다.
  • 만들어진 Object(객체)가 Controller 호출시 메서드의 파라미터로 전달된다.
• supportsParameter() 를 사용하는 다양한 ArgumentResolver 구현체

ReturnValueHandler

📌 Spring MVC에서 컨트롤러 메서드가 반환하는 값을 처리하여 HTTP 응답에 맞게 변환하는 역할을 하는 인터페이스로 컨트롤러 메서드가 실행된 후 그 반환값을 HTTP 응답의 본문에 적절히 담아 전송할 수 있도록 도와준다.

Spring MVC의 주요 컴포넌트 요약 

1. ArgumentResolver

• 역할: 컨트롤러 메서드의 입력 파라미터를 동적으로 생성하여 주입.
• 일상 예시:
  • "음식점에서 메뉴를 보고 '김치찌개'를 주문하면, 요리사가 요청에 맞는 재료를 준비해서 요리를 시작한다."
  • 여기서 김치찌개라는 요청을 기반으로 필요한 재료(데이터)를 동적으로 준비하는 역할이 ArgumentResolver입니다.

예제 코드:

@GetMapping("/user")
public String getUser(@RequestParam String name) {
    return "Hello " + name;
}

동작:

• 클라이언트 요청: /user?name=John
• **ArgumentResolver**가 name 값을 쿼리 파라미터에서 추출해 메서드 파라미터에 전달.

2. RequestMappingHandlerAdapter

• 역할:
  • 클라이언트의 HTTP 요청을 적절한 컨트롤러 메서드에 매핑.
  • 요청 파라미터를 ArgumentResolver로 처리하고, 응답 값을 ReturnValueHandler로 처리.
• 일상 예시:
  • "레스토랑에서 웨이터가 손님의 요청을 듣고 적절한 요리사에게 요청을 전달한다."
  • 웨이터(RequestMappingHandlerAdapter)가 요청을 받아, 요리사(Controller)에게 적절히 전달하고 결과를 받아 클라이언트에 응답.

예제 코드:

@PostMapping("/order")
public String placeOrder(@RequestBody OrderDto order) {
    return "Order received for: " + order.getItemName();
}

동작:

1. **RequestMappingHandlerAdapter**가 요청 /order를 탐지하고, 해당 메서드를 호출.
2. ArgumentResolver를 사용해 요청 본문(JSON)을 OrderDto로 변환.
3. 메서드 실행 후 반환된 값을 ReturnValueHandler로 처리.

3. ReturnValueHandler

• 역할: 컨트롤러 메서드가 반환한 값을 적절한 형식으로 변환하여 클라이언트로 전송.
• 일상 예시:
  • "요리사가 음식을 만들어서 웨이터가 손님에게 적절한 포장(접시 또는 테이크아웃 박스)으로 전달한다."
  • 반환된 결과 데이터를 JSON, HTML, XML 등 클라이언트가 원하는 형식으로 변환하는 역할이 ReturnValueHandler입니다.

예제 코드:

@GetMapping("/status")
public ResponseEntity<String> getStatus() {
    return ResponseEntity.ok("Service is running");
}

동작:

1. 컨트롤러 메서드가 ResponseEntity를 반환.
2. **ReturnValueHandler**가 반환된 값을 HTTP 응답 본문에 쓰고, 상태 코드와 헤더를 설정.

요약된 동작 흐름 (일상 비유로 연결)

1. 클라이언트 요청: 손님이 "김치찌개 주문" 요청.
   • 클라이언트가 /order?item=kimchiStew로 HTTP 요청.
2. RequestMappingHandlerAdapter: 웨이터가 요청을 접수.
   • URL, HTTP 메서드 등에 따라 적절한 컨트롤러 메서드 매핑.
3. ArgumentResolver: 요리사가 요청에 필요한 재료 준비.
   • 쿼리 파라미터, 요청 본문 등을 읽어 메서드 파라미터에 맞는 데이터 생성.
4. Controller 처리: 요리사가 음식을 만듦.
   • 컨트롤러 로직이 비즈니스 처리를 수행.
5. ReturnValueHandler: 웨이터가 음식을 손님에게 전달.
   • 컨트롤러 결과를 JSON, HTML 등 클라이언트가 이해할 수 있는 형식으로 변환.

통합 예제

@RestController
public class ExampleController {

    @GetMapping("/user")
    public String getUser(@RequestParam String name) { // ArgumentResolver 처리
        return "Hello " + name; // ReturnValueHandler 처리
    }

    @PostMapping("/order")
    public ResponseEntity<OrderResponse> placeOrder(@RequestBody OrderDto order) {
        // ArgumentResolver 처리
        OrderResponse response = new OrderResponse(order.getItemName(), "Processing");
        return ResponseEntity.ok(response); // ReturnValueHandler 처리
    }
}

요청/응답 흐름:

1. 클라이언트 요청: GET /user?name=John
2. ArgumentResolver:
   • RequestParamMethodArgumentResolver가 쿼리 파라미터 name=John을 추출해 메서드 파라미터에 전달.
3. 컨트롤러 실행: return "Hello John";
4. ReturnValueHandler:
   • 반환값을 HTTP 응답 본문(Hello John)에 작성.

비유와 코딩을 연결한 간단 정리

• ArgumentResolver: 요청, 데이터(재료)를 준비.
• RequestMappingHandlerAdapter: 요청을 전달하고 전체 과정을 조율(웨이터).
• ReturnValueHandler: 응답, 반환값(요리 결과)을 클라이언트에게 적절히 포장해 전달.

이 과정을 통해 Spring MVC는 클라이언트의 요청을 유연하고 효과적으로 처리합니다!

Spring 이론

웹 개발 방식

스프링 개발의 로드맵

📌 아래는 흔히 스프링 개발에서 사용하는 웹 개발 형식 중 MVC의 내부적 흐름을 표기한 그림이다.

위의 로드맵을 머리속에 그리고 아래의 글을 보면 이해가 쉽다.

전체 개발 단계 요약

1. 기획 및 설계: 목표 정의, 와이어프레임 작성, 기술 스택 결정.
2. 환경 설정: GitLab, AWS, 배포 환경 구성.
3. CI/CD 구축: 자동화된 빌드, 테스트, 배포 설정.
4. 프론트엔드 개발: React로 사용자 인터페이스 개발.
5. 백엔드 개발: NestJS와 RDS MySQL로 서버 및 데이터베이스 구축.
6. 코드 리뷰 및 협업: GitLab 머지 리퀘스트 및 이슈 관리.
7. 테스트 및 최적화: 단위/통합 테스트, 성능 최적화.
8. 출시 및 유지보수: 공식 릴리스 및 지속적 개선.

Spring Framework

📌 Spring Framework는 자바 기반의 애플리케이션 개발을 위한 오픈 소스 프레임워크로, 기업용 애플리케이션 개발에서 널리 사용됩니다. 경량 프레임워크로 시작했지만, 현재는 복잡한 애플리케이션 개발을 단순화하고 생산성을 높이는 강력한 생태계를 제공한다.

Spring Framework 주요 구성 요소

Spring Framework 구성 요소 설명

= 아래는 사전적인 정의로 이해하기 쉽게 아래 접은 글에 설명을 추가해 두었다.

1. Core Container:
   • Core : Spring의 핵심 모듈로, IoC(Inversion of Control)와 DI(Dependency Injection)를 처리.
   • Beans: 객체의 생성, 초기화, 주입, 소멸 등을 관리.
   • Context: ApplicationContext와 같은 고급 IoC 기능 제공.
   • Expression Language: EL을 사용해 객체 속성에 동적으로 접근.
2. AOP:
   • 애플리케이션에서 공통적으로 반복되는 로직(로깅, 보안 등)을 분리.
   • 코드 중복 없이 비즈니스 로직과 공통 로직을 분리 가능.
3. Data Access/Integration:
   • 데이터 접근 및 통합 작업을 단순화.
   • JDBC와 ORM을 위한 템플릿 클래스 제공.
   • 트랜잭션 관리 기능을 제공하여 데이터 무결성을 유지.
4. Web (MVC/Remoting):
   • Spring MVC를 사용해 RESTful API와 동적 웹 애플리케이션을 개발.
   • Servlet과 통합하여 요청 처리.
   • 기존 Struts 프레임워크와 통합 가능.
5. Test:
   • JUnit, TestNG와의 통합으로 단위 테스트와 통합 테스트를 지원.
   • IoC 컨테이너를 사용하여 애플리케이션 컨텍스트를 로드하고 테스트.

IoC와 DI

public class Chef {
    private Ingredient ingredient;

    public Chef() {
        this.ingredient = new Ingredient(); // 요리사가 직접 재료를 생성
    }

    public void cook() {
        System.out.println("Cooking with " + ingredient.getName());
    }
}

public class Ingredient {
    public String getName() {
        return "Tomatoes";
    }
}

public class Chef {
    private Ingredient ingredient;

    // 의존성 주입 (DI)
    public Chef(Ingredient ingredient) {
        this.ingredient = ingredient;
    }

    public void cook() {
        System.out.println("Cooking with " + ingredient.getName());
    }
}

public class Ingredient {
    public String getName() {
        return "Tomatoes";
    }
}

// Spring Configuration
@Configuration
public class AppConfig {
    @Bean
    public Ingredient ingredient() {
        return new Ingredient(); // 의존성 생성
    }

    @Bean
    public Chef chef(Ingredient ingredient) {
        return new Chef(ingredient); // 의존성 주입
    }
}

AOP

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.*;

@Aspect
@Component
public class ExecutionTimeAspect {

    @Around("execution(* com.example.service.*.*(..))")
    public Object measureExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        long startTime = System.currentTimeMillis();
        Object result = joinPoint.proceed(); // 메서드 실행
        long endTime = System.currentTimeMillis();
        System.out.println("Execution time of " + joinPoint.getSignature() + ": " + (endTime - startTime) + " ms");
        return result;
    }
}

@Around("execution(* com.example.service.*.*(..))")

@Service
public class ExampleService {
    public void exampleMethod() {
        // 비즈니스 로직
        System.out.println("Executing exampleMethod...");
    }
}

Spring 구조 흐름

• Core Container는 Spring의 기반 기능을 제공.
• AOP는 비즈니스 로직과 공통 로직을 분리.
• Data Access/Integration은 데이터베이스와의 통신 및 메시지 처리를 단순화.
• Web 모듈은 MVC를 지원하여 웹 애플리케이션 개발을 간소화.
• Test는 Spring 애플리케이션의 안정성을 검증.

Spring Framework 특징

스프링 컨테이너(Spring Container)와 스프링 빈(Spring Bean)

1. 스프링 컨테이너(Spring Container)란?

스프링 컨테이너는 스프링 프레임워크의 핵심 컴포넌트로, 애플리케이션에서 사용하는 객체(빈)를 생성, 관리, 의존성 주입, 생명 주기 관리를 수행하는 도구입니다.

+ 실제로 스프링 컨테이너는 위의 IOC와 DI 개념을 구현하는 도구이다.

스프링 컨테이너의 주요 역할

1. 객체(스프링 빈) 생성:
   • 애플리케이션에서 필요한 객체를 생성합니다.
2. 의존성 주입(DI):
   • 객체 간의 의존성을 설정하고 주입합니다.
3. 객체 생명 주기 관리:
   • 객체의 생성, 초기화, 사용, 소멸 과정을 관리합니다.
4. 빈의 스코프 설정:
   • 객체가 싱글톤인지, 매번 새로운 객체인지 스코프를 정의하고 관리합니다.

2. 스프링 빈(Spring Bean)이란?

스프링 컨테이너가 관리하는 객체를 **스프링 빈(Spring Bean)**이라고 합니다.

스프링 빈의 특징

• 스프링 컨테이너에 의해 생성 및 관리됩니다.
• 기본적으로 **싱글톤(하나의 인스턴스를 공유)**으로 관리됩니다.
• 개발자가 빈을 정의하면, 컨테이너가 이를 관리하고, 의존성을 자동으로 주입합니다.
• 스프링 빈은 보통 어노테이션(@Component, @Service, @Repository, @Controller) 또는 XML 설정으로 등록합니다.

[그래서 스프링 빈은 객체를 어떻게 관리할까?]

@Component
class NotificationService {
    private final MessageService messageService;

    @Autowired
    public NotificationService(MessageService messageService) {
        this.messageService = messageService; // 의존성 주입
    }

    public void notify(String message) {
        messageService.sendMessage(message);
    }
}

@Component
class NotificationService {
    private MessageService messageService;

    @Autowired
    public void setMessageService(MessageService messageService) {
        this.messageService = messageService; // 의존성 주입
    }

    public void notify(String message) {
        messageService.sendMessage(message);
    }
}

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.stereotype.Component;

@Component
class ExampleBean implements InitializingBean, DisposableBean {
    // 빈 생성자
    public ExampleBean() {
        System.out.println("1. 빈 생성");
    }

    // 의존성 주입 후 호출
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("2. 빈 초기화");
    }

    // 빈 소멸 전 호출
    @Override
    public void destroy() throws Exception {
        System.out.println("3. 빈 소멸");
    }
}

// 메인 클래스
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {
    public static void main(String[] args) {
        // 컨테이너 생성 및 빈 관리 시작
        var context = new AnnotationConfigApplicationContext(AppConfig.class);

        // ExampleBean 사용
        ExampleBean exampleBean = context.getBean(ExampleBean.class);

        // 컨테이너 종료 및 빈 소멸
        context.close();
    }
}

1. 빈 생성
2. 빈 초기화
3. 빈 소멸

3. 스프링 컨테이너와 스프링 빈의 관계

• 스프링 컨테이너는 스프링 빈을 관리하는 도구입니다.
• 개발자는 스프링 컨테이너에 객체(빈)를 등록하고, 컨테이너는 이 빈을 생성하고 관리합니다.
• 스프링 컨테이너는 애플리케이션 실행 시 빈을 생성하고, 의존성을 주입하며, 생명 주기를 관리합니다.

4. 일상적인 예시

1) 스프링 컨테이너와 스프링 빈

• 스프링 컨테이너: **관리인(컨테이너)**이 빵집의 모든 직원과 재료를 관리.
• 스프링 빈: 관리인이 관리하는 **직원(객체)**과 재료(의존성).

비유

• 빵집의 모든 직원은 관리인의 관리하에 빵을 만듭니다.
• 직원들 간의 의존성(예: 반죽 -> 오븐 -> 포장)은 관리인이 연결해줍니다.
• 관리인이 직원의 고용, 교체, 해고(생명 주기)를 관리합니다.

5. 코드 예제

1) 스프링 컨테이너와 빈 등록

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.stereotype.Component;

// 메시지 서비스 인터페이스
interface MessageService {
    void sendMessage(String message);
}

// EmailService 구현체
@Component
class EmailService implements MessageService {
    public void sendMessage(String message) {
        System.out.println("Sending Email: " + message);
    }
}

// NotificationService 클래스
@Component
class NotificationService {
    private final MessageService messageService;

    // 생성자를 통한 의존성 주입
    public NotificationService(MessageService messageService) {
        this.messageService = messageService;
    }

    public void notify(String message) {
        messageService.sendMessage(message);
    }
}

// 스프링 설정 클래스
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan(basePackages = "com.example")
class AppConfig {
}

// Main 클래스
public class Main {
    public static void main(String[] args) {
        // 스프링 컨테이너 생성
        ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);

        // 스프링 컨테이너에서 NotificationService 빈 가져오기
        NotificationService notificationService = context.getBean(NotificationService.class);
        notificationService.notify("Hello, Spring!");
    }
}

2) 코드 설명

1. 스프링 컨테이너 생성:
   • ApplicationContext를 통해 스프링 컨테이너를 생성.
   • AppConfig 클래스에서 @ComponentScan으로 스캔한 클래스들을 빈으로 등록.
2. 빈 생성 및 관리:
   • @Component로 등록된 EmailService와 NotificationService는 스프링 컨테이너에 의해 관리됨.
3. 의존성 주입:
   • NotificationService의 생성자에 MessageService 타입의 객체(EmailService)가 자동으로 주입.

6. 정리 표

7. 스프링 컨테이너와 스프링 빈의 관계

1. 컨테이너는 빈을 생성하고 관리:
   • 스프링 컨테이너는 빈을 생성하고, 애플리케이션에서 필요한 의존성을 주입하며, 빈의 생명 주기를 관리합니다.
2. 빈은 컨테이너에 의해 관리되는 객체:
   • 빈은 컨테이너가 생성, 관리하며, 개발자는 컨테이너를 통해 빈을 사용합니다.
   • 빈은 컨테이너가 없으면 독립적으로 존재할 수 없습니다.

결론

• 스프링 컨테이너는 스프링 프레임워크에서 IOC와 DI를 구현하는 핵심 도구로, 애플리케이션의 객체 생성과 의존성 주입을 관리합니다.
• 스프링 빈은 스프링 컨테이너가 관리하는 객체로, 개발자는 이 빈을 사용하여 비즈니스 로직을 구현합니다.
• 스프링 컨테이너와 스프링 빈의 관계는 관리자와 직원의 관계로 비유할 수 있습니다.
  컨테이너가 모든 객체를 생성하고 관리하며, 빈은 각자의 역할에 맞는 작업을 수행합니다.

싱글톤 컨테이너 (Singleton Container)

1. 싱글톤 컨테이너란?

• 싱글톤 컨테이너는 스프링 컨테이너가 애플리케이션 실행 시 한 번 생성된 빈(Bean) 객체를 재사용하도록 관리하는 컨테이너입니다.
• 스프링에서 기본 빈 스코프는 싱글톤이며, 이는 애플리케이션 내에서 동일한 빈 객체가 공유된다는 것을 의미합니다.
• 즉, 동일한 타입의 빈을 여러 번 요청해도 동일한 객체의 참조를 반환합니다.

2. 왜 싱글톤 컨테이너를 사용하는가?

1. 효율적인 메모리 관리:
   • 객체를 한 번만 생성하고 재사용하므로 메모리 낭비를 줄일 수 있습니다.
2. 애플리케이션의 일관성 유지:
   • 여러 컴포넌트에서 같은 빈 객체를 사용하므로 상태 관리가 용이합니다.
3. 객체 생성 비용 절감:
   • 빈을 필요할 때마다 새로 생성하는 대신, 이미 생성된 객체를 재사용하여 성능을 향상시킵니다.

3. 싱글톤 컨테이너의 동작 방식

1. 스프링 컨테이너는 빈 정의를 스캔하여 메모리에 빈 객체를 한 번만 생성합니다.
2. 이후 빈이 필요할 때마다 동일한 객체의 참조를 반환합니다.
3. 기본적으로 모든 빈은 싱글톤 스코프로 관리되지만, 필요에 따라 프로토타입 스코프 등으로 변경할 수 있습니다.

4. 코드 예제

싱글톤 컨테이너 동작

import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.stereotype.Component;

@Component
class SingletonBean {
    public SingletonBean() {
        System.out.println("SingletonBean 객체 생성!");
    }

    public void doSomething() {
        System.out.println("SingletonBean 동작 수행!");
    }
}

public class Main {
    public static void main(String[] args) {
        // 스프링 컨테이너 생성
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(Main.class.getPackageName());

        // 동일한 빈을 두 번 조회
        SingletonBean bean1 = context.getBean(SingletonBean.class);
        SingletonBean bean2 = context.getBean(SingletonBean.class);

        // 메서드 호출
        bean1.doSomething();

        // 객체 비교
        System.out.println("bean1 == bean2: " + (bean1 == bean2));

        // 컨테이너 종료
        context.close();
    }
}

실행 결과

SingletonBean 객체 생성!
SingletonBean 동작 수행!
bean1 == bean2: true

5. 코드 설명

1. SingletonBean 정의:
   • @Component를 사용해 스프링 컨테이너에 빈으로 등록.
   • 컨테이너 초기화 시 객체가 한 번 생성됩니다.
2. 컨테이너에서 빈 요청:
   • 두 번 getBean() 메서드를 호출했지만, 동일한 객체를 반환했습니다.
3. 싱글톤 보장:
   • bean1과 bean2는 동일한 객체임을 확인(bean1 == bean2: true).

6. 싱글톤 컨테이너의 한계와 주의점

1. 공유 객체이므로 상태 관리 주의:
   • 싱글톤 빈은 애플리케이션 전역에서 공유되므로, **빈 내부에 상태를 유지(필드에 값 저장 등)**하면 동시성 문제가 발생할 수 있습니다.
   • 상태를 유지하지 않고 **무상태(stateless)**로 설계하는 것이 중요합니다.
2. 멀티스레드 환경에서 동시성 문제:
   • 공유되는 객체이므로 여러 스레드에서 동시에 접근할 경우 동시성 문제가 발생할 수 있습니다.

7. 요약

8. 싱글톤과 프로토타입 비교

9. 결론

• 싱글톤 컨테이너는 애플리케이션 전반에서 하나의 객체를 공유하도록 관리하는 방식으로, 메모리와 성능 면에서 효율적입니다.
• 스프링의 빈은 기본적으로 싱글톤으로 관리되며, 이를 통해 객체 재사용이 보장됩니다.
• 하지만 공유 객체이므로 상태를 유지하지 않도록 설계해야 하며, 동시성 문제를 피하기 위해 빈을 **무상태(stateless)**로 설계하는 것이 중요합니다.
• 필요 시 프로토타입이나 다른 스코프를 사용하여 빈의 생명 주기를 유연하게 관리할 수 있습니다.

컴포넌트 스캔 (Component Scan)

@SpringBootApplication
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan(basePackages = "com.example")
public class AppConfig {
}

@ComponentScan(basePackages = {"com.example.service", "com.example.repository"})

@ComponentScan(basePackageClasses = {MyService.class, MyRepository.class})

@ComponentScan(
    basePackages = "com.example",
    includeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = MyCustomAnnotation.class),
    excludeFilters = @ComponentScan.Filter(type = FilterType.REGEX, pattern = "com\\.example\\.exclude\\..*")
)

com.example
 ├── MainApplication.java
 ├── controller
 │    └── MyController.java
 ├── service
 │    └── MyService.java
 └── repository
      └── MyRepository.java

package com.example.controller;

import com.example.service.MyService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    @Autowired
    private MyService myService;

    @GetMapping("/")
    public String home() {
        return myService.sayHello();
    }
}

package com.example.service;

import org.springframework.stereotype.Service;

@Service
public class MyService {
    public String sayHello() {
        return "Hello, Component Scan!";
    }
}

package com.example.repository;

import org.springframework.stereotype.Repository;

@Repository
public class MyRepository {
    // Data access logic
}

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MainApplication {
    public static void main(String[] args) {
        SpringApplication.run(MainApplication.class, args);
    }
}

빈 스코프 (Bean Scope)

1. 빈 스코프란?

스프링 빈(Bean) 스코프는 스프링 컨테이너가 빈의 생성과 관리 주기를 결정하는 방식을 의미합니다.
즉, 빈이 언제 생성되고, 몇 번 생성되며, 어떤 범위에서 공유되는지를 정의합니다.

+ 스프링 컨테이너는 프로토타입 빈을 생성하고 의존관계 주입, 초기화까지만 처리한다. 클라이언트에 빈을 반환한 이후에는 스프링 컨테이너는 해당 빈을 관리하지 않는다. 그렇기에 스프링을 떠난 빈은 온전히 클라이언트가 생명주기를 관리해야하며, 그래서 @PreDestory같은 스프링의 어노테이션으로 종료가 안된다. = 이 순간부터 스프링의 객체가 아니다.

2. 스프링이 지원하는 빈 스코프 종류

3. 빈 스코프별 동작 방식

1) Singleton Scope (싱글톤 스코프)

• 특징:
  • 컨테이너 내에 하나의 빈 인스턴스만 생성.
  • 모든 요청에서 동일한 객체를 반환.
• 사용 사례:
  • 공유 데이터나 상태를 가지지 않는 서비스 객체, 비즈니스 로직 처리 클래스.

@Service
public class MySingletonService {
    public String getMessage() {
        return "This is a Singleton Bean";
    }
}

2) Prototype Scope (프로토타입 스코프)

• 특징:
  • 요청할 때마다 새로운 빈 인스턴스를 생성.
  • 빈의 생명 주기를 컨테이너가 관리하지 않음(직접 관리해야 함).
• 사용 사례:
  • 상태가 있는 객체(예: 임시 데이터 저장소).

@Component
@Scope("prototype")
public class MyPrototypeService {
    public String getMessage() {
        return "This is a Prototype Bean";
    }
}

주요 차이점:

• 싱글톤은 동일한 객체를 공유하지만, 프로토타입은 요청마다 새로운 객체를 생성.

3) Request Scope (요청 스코프)

• 특징:
  • HTTP 요청당 하나의 빈 생성.
  • 요청이 종료되면 빈도 소멸.
• 사용 사례:
  • 각 요청마다 고유한 상태를 유지해야 하는 경우.

@Component
@Scope("request")
public class MyRequestBean {
    private String value;

    public String getValue() {
        return value;
    }

    public void setValue(String value) {
        this.value = value;
    }
}

주의: 요청 스코프는 웹 애플리케이션 환경(@RestController, @Controller)에서만 사용할 수 있습니다.

4) Session Scope (세션 스코프)

• 특징:
  • HTTP 세션당 하나의 빈 생성.
  • 세션이 종료되면 빈도 소멸.
• 사용 사례:
  • 사용자별 데이터를 유지해야 하는 경우(예: 로그인 상태, 장바구니).

@Component
@Scope("session")
public class MySessionBean {
    private String userData;

    public String getUserData() {
        return userData;
    }

    public void setUserData(String userData) {
        this.userData = userData;
    }
}

5) Application Scope (애플리케이션 스코프)

• 특징:
  • 웹 애플리케이션 컨텍스트 전체에서 하나의 빈 공유.
• 사용 사례:
  • 애플리케이션 전역에서 유지해야 하는 데이터.

@Component
@Scope("application")
public class MyApplicationBean {
    public String getGlobalValue() {
        return "This is an Application Scoped Bean";
    }
}

6) Websocket Scope (웹소켓 스코프)

• 특징:
  • WebSocket 연결당 하나의 빈 생성.
  • 연결 종료 시 빈도 소멸.
• 사용 사례:
  • WebSocket 연결별로 데이터를 유지해야 하는 경우.

@Component
@Scope("websocket")
public class MyWebsocketBean {
    private String connectionId;

    public String getConnectionId() {
        return connectionId;
    }

    public void setConnectionId(String connectionId) {
        this.connectionId = connectionId;
    }
}

4. 빈 스코프 설정 방법

1) 어노테이션 사용

• **@Scope**를 사용하여 빈의 스코프를 지정합니다.

@Component
@Scope("prototype") // 프로토타입 스코프 지정
public class MyPrototypeBean {
    // 빈의 내용
}

2) XML 설정 (스프링 설정 파일 사용)

<bean id="myBean" class="com.example.MyBean" scope="prototype"/>

3) Java Config 사용

@Bean
@Scope("prototype") // 프로토타입 스코프 지정
public MyPrototypeBean myPrototypeBean() {
    return new MyPrototypeBean();
}

5. 정리 표

6. 빈 스코프 선택 기준

1. 싱글톤(Singleton):
   • 공유 데이터를 가지지 않으며, 애플리케이션 전역에서 빈을 공유해야 할 때 사용.
   • 기본값이므로 특별한 이유가 없다면 싱글톤을 사용하는 것이 권장됩니다.
2. 프로토타입(Prototype):
   • 상태를 가지는 객체가 필요하거나 요청 시마다 새로운 인스턴스가 필요할 때.
3. 요청/세션/애플리케이션(Web):
   • 웹 애플리케이션 환경에서 요청별, 세션별, 또는 애플리케이션 전역 데이터를 유지해야 할 때 사용.
4. 웹소켓(WebSocket):
   • WebSocket 기반 통신에서 연결별 데이터를 유지해야 할 때 사용.

7. 결론

• 스프링 빈 스코프는 빈의 생성 주기와 공유 범위를 제어하는 중요한 설정입니다.
• 기본값은 **싱글톤(Singleton)**이며, 대부분의 경우 효율적이고 적합하지만, 특정 상황에서는 프로토타입, 요청, 세션, 애플리케이션 스코프를 활용해야 합니다.
• 스코프를 적절히 설정하면 애플리케이션의 효율성과 유지보수성이 크게 향상됩니다.

Spring Boot

📌 Spring Framework를 기반으로 하여 간편하고 신속하게 애플리케이션을 개발할 수 있도록 도와주는 도구이다.

[1]  Spring Boot의 주요 특징

[2]  Spring Boot의 장점

1. 빠른 시작:
   • Spring Boot는 자동 설정 및 기본적인 템플릿을 제공하여, 애플리케이션을 몇 가지 설정만으로 빠르게 시작할 수 있습니다. @SpringBootApplication 어노테이션을 추가하면, 기본적인 설정이 자동으로 이루어지고, 애플리케이션을 실행할 수 있는 상태가 됩니다.
2. 설정 최소화:
   • Spring Boot는 많은 설정을 자동으로 처리하므로 개발자는 비즈니스 로직에만 집중할 수 있습니다. 예를 들어, 데이터베이스 설정, 서버 설정등 대부분의 설정을 자동으로 처리하여 개발자가 별도로 신경 쓸 필요가 없습니다.
3. 내장 서버:
   • 내장 서버를 제공하여 별도의 외부 웹 서버(Tomcat, Jetty 등이 내장되어 있다.)를 설치할 필요 없이 바로 실행할 수 있습니다. 이는 애플리케이션의 배포를 간소화하고, 실행 파일 하나로 애플리케이션을 배포할 수 있게 만듭니다.
4. 생산성 향상:
   • Spring Boot는 개발자가 빠르게 단독으로 실행할 수 있는 애플리케이션을 작성하고 실행할 수 있도록 돕기 위해 많은 스타터 의존성을 제공합니다. 예를 들어, 웹 애플리케이션을 만들기 위한 spring-boot-starter-web, 데이터베이스 연동을 위한 spring-boot-starter-data-jpa 등이 있습니다.
5. DevTools:
   • Spring Boot는 개발 중에 자동 재시작 및 Hot swapping을 지원하여, 개발자가 코드 수정 후 애플리케이션을 다시 시작하지 않고도 변경 사항을 바로 반영할 수 있도록 돕습니다.

[3]  Spring Boot 애플리케이션 구조

1. 애플리케이션 클래스
   • @SpringBootApplication 어노테이션이 붙은 클래스는 Spring Boot 애플리케이션의 진입점입니다. 이 클래스는 자동으로 필요한 설정을 수행하고 애플리케이션을 실행합니다.

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

1. 자동 설정:
   • Spring Boot는 애플리케이션을 실행할 때, 주어진 환경에 맞춰 자동으로 설정을 적용합니다. 예를 들어, 데이터베이스가 설정되면 자동으로 DataSource와 관련된 설정이 적용됩니다.
2. 프로퍼티 파일:
   • Spring Boot는 application.properties 또는 application.yml 파일을 통해 애플리케이션의 설정을 관리할 수 있습니다. 데이터베이스 연결 정보, 서버 포트, 로깅 수준 등 다양한 설정을 이 파일에서 처리합니다.
3. 내장 서버:
   • Spring Boot는 기본적으로 내장된 Tomcat 서버를 포함하고 있으며, 설정에 따라 다른 내장 서버(Undertow, Jetty 등)를 사용할 수 있습니다.

[4]  Spring Boot 애플리케이션 실행

1. Maven 또는 Gradle을 사용한 빌드 후 실행:
   • 애플리케이션을 빌드하고 실행하려면, mvn spring-boot:run 또는 gradle bootRun 명령을 사용할 수 있습니다.
2. JAR 파일로 실행:
   • Spring Boot 애플리케이션을 JAR 파일로 빌드한 후, java -jar 명령어로 실행할 수 있습니다.

java -jar myapp.jar

[5]  Spring Boot 사용 예시

• 간단한 RESTful 웹 서비스:

@RestController
@RequestMapping("/api")
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "Hello, World!";
    }
}

• 자동 설정 예시: Spring Boot는 데이터베이스 연결을 자동으로 처리할 수 있습니다. 예를 들어, 데이터베이스 설정을 application.properties에서 지정하면, Spring Boot는 이를 자동으로 인식하고 설정을 완료합니다.

spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=root
spring.datasource.password=secret

Spring MVC

Spring MVC 구조

Spring MVC 실행 흐름 요약

Spring MVC 주요 인터페이스 요약

Spring MVC 주요 컴포넌트와 동작 흐름

HttpMessageConverter

HttpMessageConverter의 역할

• 클라이언트와 서버 간의 HTTP 요청과 응답을 처리할 때 데이터 형식 변환을 담당 합니다. 
• HTTP 요청/응답 본문(body)의 데이터를 객체로 변환하거나, 객체를 특정 형식(JSON, XML 등)으로 변환하여 HTTP 응답 본문에 적합하게 변환하는 역할을 담당합니다.
• 주로 REST API에서 사용되며, JSON이나 XML 데이터를 객체로 역직렬화하거나 객체를 JSON, XML 형식으로 직렬화하는 데 사용됩니다.
• [ View를 응답하는 것이 아닌, Rest API(HTTP API)로 JSON, TEXT, XML 등의 데이터를 응답 Message Body에 직접 입력하는 경우 HttpMessageConverter를 사용합니다. ]

HttpMessageConverter와 다른 컴포넌트의 관계

1. DispatcherServlet:
   • 요청이 들어오면, HandlerMapping과 HandlerAdapter를 통해 적절한 핸들러(Controller)를 실행합니다.
2. HandlerAdapter:
   • 핸들러(Controller)에서 반환된 객체(@ResponseBody 또는 ResponseEntity)를 처리하는 과정에서 HttpMessageConverter를 호출합니다.
   • HttpMessageConverter는 데이터를 변환한 후, View를 렌더링하거나 HTTP 응답 본문에 데이터를 직접 작성합니다.
3. ViewResolver & View:
   • ViewResolver는 논리적 뷰 이름을 실제 뷰로 변환하지만, 만약 JSON이나 XML 데이터로 응답해야 한다면 HttpMessageConverter가 뷰 렌더링 대신 데이터를 직접 변환하여 응답 본문으로 반환합니다.

• 요청시에는 Argument Resolver를 사용합니다.
• 응답시에는 ReturnValueHandler를 사용합니다.

HttpMessageConverter의 동작 흐름

1. 클라이언트가 JSON 데이터를 포함한 HTTP 요청을 보냅니다.
2. DispatcherServlet이 요청을 HandlerAdapter로 전달합니다.
3. HandlerAdapter는 컨트롤러(핸들러)를 호출하여 요청을 처리합니다.
4. 컨트롤러가 객체(예: @ResponseBody 또는 ResponseEntity)를 반환합니다.
5. HandlerAdapter가 반환된 데이터를 처리하기 위해 적절한 **HttpMessageConverter**를 선택합니다.
6. HttpMessageConverter는 데이터를 변환(JSON ↔ 객체)하여 응답 본문에 작성하거나, 요청 본문에서 데이터를 추출합니다.

HttpMessageConverter가 처리하는 경우

• 요청 데이터 변환:
  • JSON, XML, plain text 데이터를 컨트롤러가 처리할 수 있는 Java 객체로 변환.
• 응답 데이터 변환:
  • 컨트롤러에서 반환한 Java 객체를 JSON, XML, plain text 형식으로 변환하여 클라이언트에 전달.

HttpMessageConverter가 없는 경우와 있는 경우

없는 경우:

@RestController
public class MyController {
    @GetMapping("/data")
    public String getData() {
        return "{ \"key\": \"value\" }"; // 직접 JSON 문자열 작성
    }
}

• JSON 데이터를 직접 작성해야 하므로 불편하고 오류 가능성이 높습니다.

있는 경우 (HttpMessageConverter 사용):

@RestController
public class MyController {
    @GetMapping("/data")
    public MyResponse getData() {
        return new MyResponse("value"); // 객체를 반환
    }
}

class MyResponse {
    private String key;

    public MyResponse(String key) {
        this.key = key;
    }

    // Getter/Setter
}

• 컨트롤러는 Java 객체를 반환하며, HttpMessageConverter가 이를 JSON으로 변환하여 클라이언트에 응답합니다.

정리 표

컴포넌트 역할

결론

• HttpMessageConverter는 HandlerAdapter와 View 사이에서 데이터 변환을 담당합니다.
• 요청 데이터(JSON, XML 등)를 Java 객체로 변환하거나, 컨트롤러에서 반환한 객체를 JSON, XML 등으로 변환해 응답 본문으로 작성하는 데 사용됩니다.
• REST API 개발에서 매우 중요한 역할을 하며, Spring MVC의 데이터 처리 흐름을 간단하게 만들어줍니다.

WebMvcConfigurer

• WebMvcConfigurer는 스프링 프레임워크에서 제공하는 인터페이스로, 스프링 MVC의 동작을 사용자 정의할 수 있는 방법을 제공합니다.
• 기본적으로 스프링은 자동 설정(Auto Configuration)을 통해 대부분의 MVC 설정을 처리하지만, 필요한 경우 개발자가 이를 커스터마이징할 수 있도록 WebMvcConfigurer를 제공합니다.

1. WebMvcConfigurer의 역할

WebMvcConfigurer를 구현하여 다음과 같은 스프링 MVC 동작을 커스터마이징할 수 있습니다:

1. 요청 매핑(Custom Request Mapping):
   • 특정 URL 패턴의 요청 처리 방식을 사용자 정의.
2. CORS 설정:
   • 특정 도메인에서의 Cross-Origin 요청을 허용하거나 제한.
3. 정적 리소스 핸들링:
   • 정적 리소스(예: CSS, JS, 이미지) 경로 설정.
4. 뷰 컨트롤러(View Controller) 추가:
   • 컨트롤러 없이 URL에 대해 바로 뷰를 반환하도록 설정.
5. 포맷터(Formatter) 및 변환기(Converter) 등록:
   • 커스텀 데이터 타입 변환 또는 데이터 포맷팅.
6. 인터셉터 등록:
   • 요청 전후 처리에 대한 로직 추가.
7. MessageConverter 등록:
   • 요청/응답 데이터의 변환 규칙 추가 또는 커스터마이징.

2. WebMvcConfigurer를 사용하는 방법

1) 기본적인 구현

스프링에서 WebMvcConfigurer를 구현하는 클래스는 다음과 같습니다:

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {
    // 필요한 메서드 오버라이드
}

• @Configuration:
  • 이 클래스가 설정 클래스임을 나타냅니다.
• WebMvcConfigurer:
  • 인터페이스로, 필요한 메서드만 선택적으로 오버라이드할 수 있습니다.

3. WebMvcConfigurer에서 커스터마이징 예제

1) 정적 리소스 경로 설정

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.ResourceHandlerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/static/**") // URL 패턴
                .addResourceLocations("classpath:/static/"); // 실제 리소스 경로
    }
}

• 설명:
  • /static/** URL 요청은 classpath:/static/ 경로의 정적 리소스로 매핑됩니다.
  • 예: /static/image.png 요청 → src/main/resources/static/image.png로 응답.

2) CORS 설정

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**") // 특정 URL 패턴
                .allowedOrigins("http://example.com") // 허용할 도메인
                .allowedMethods("GET", "POST"); // 허용할 HTTP 메서드
    }
}

• 설명:
  • /api/** 경로의 요청에 대해 http://example.com 도메인에서의 GET, POST 요청만 허용합니다.

3) 뷰 컨트롤러 설정

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.ViewControllerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/home") // URL 요청
                .setViewName("home"); // 반환할 뷰 이름
    }
}

• 설명:
  • /home 요청 시 컨트롤러 없이 바로 home.html을 반환합니다.

4) 인터셉터 등록

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new MyInterceptor())
                .addPathPatterns("/api/**") // 인터셉터 적용 경로
                .excludePathPatterns("/api/public/**"); // 제외 경로
    }
}

• 설명:
  • MyInterceptor가 /api/** 요청을 처리하며, /api/public/** 경로는 제외됩니다.

5) 커스텀 MessageConverter 등록

import org.springframework.context.annotation.Configuration;
import org.springframework.http.converter.HttpMessageConverter;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

import java.util.List;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        converters.add(new MyCustomMessageConverter());
    }
}

• 설명:
  • 사용자 정의 HttpMessageConverter를 등록하여 요청/응답 데이터를 커스터마이징합니다.

4. WebMvcConfigurer의 주요 메서드

5. 요약 표

6. 결론

• WebMvcConfigurer는 스프링 MVC의 동작을 세부적으로 커스터마이징할 수 있는 강력한 도구입니다.
• REST API 개발, CORS 설정, 정적 리소스 처리 등 다양한 요구사항을 처리할 때 사용됩니다.
• 필요한 메서드만 선택적으로 오버라이드하면 되므로 설정이 간단하며, 스프링의 기본 동작과 충돌 없이 동작합니다.

Spring 타입 변형 

TypeConverter

• TypeConverter는 스프링 프레임워크에서 다양한 타입 간의 변환을 지원하는 인터페이스입니다.
  주로 사용자 입력 값(HTTP 요청 파라미터, 쿼리 매개변수 등)을 컨트롤러 메서드의 매개변수에 매핑하거나, 빈의 속성을 설정할 때 사용됩니다.
• 이는 개발자가 **String 타입의 입력값을 Java 객체(예: Date, Enum 등)**로 변환하거나, Java 객체를 다시 String으로 변환할 수 있도록 돕습니다.

1. TypeConverter의 역할

1. 입력 값 변환:
   • HTTP 요청 파라미터나 쿼리 매개변수를 컨트롤러 메서드의 매개변수로 변환.
   • 예: String "123"을 Integer로 변환.
2. 빈 속성 변환:
   • 설정 파일(예: application.properties)의 속성을 빈 속성 값으로 변환.
   • 예: "2025-01-01" → LocalDate.
3. 커스텀 타입 지원:
   • 기본 제공 타입 외에 사용자 정의 타입을 지원하도록 확장 가능.

2. 기본 동작

스프링은 기본적인 타입 변환을 지원합니다. 예를 들어, 아래의 기본 변환은 자동으로 처리됩니다:

• String → int, long, double, boolean.
• String → Date, LocalDate, LocalDateTime.
• String → Enum.

3. TypeConverter의 구현 및 사용

1) 기본 사용 (스프링 자동 변환)

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    @GetMapping("/convert")
    public String convert(@RequestParam("id") int id, @RequestParam("active") boolean active) {
        return "Converted ID: " + id + ", Active: " + active;
    }
}

• 입력 요청:

  GET /convert?id=123&active=true
  

• 결과:

  Converted ID: 123, Active: true
  

스프링은 String으로 들어오는 id와 active 파라미터를 각각 int와 boolean으로 자동 변환합니다.

2) 커스텀 타입 변환기 작성

스프링의 기본 변환 외에 사용자 정의 변환기를 등록할 수 있습니다.

1. 사용자 정의 타입

public class CustomType {
    private String value;

    public CustomType(String value) {
        this.value = value;
    }

    public String getValue() {
        return value;
    }

    @Override
    public String toString() {
        return "CustomType{" +
                "value='" + value + '\'' +
                '}';
    }
}

2. TypeConverter 구현

import org.springframework.core.convert.converter.Converter;
import org.springframework.stereotype.Component;

// String -> CustomType 변환기
@Component
public class StringToCustomTypeConverter implements Converter<String, CustomType> {

    @Override
    public CustomType convert(String source) {
        return new CustomType(source);
    }
}

3. 컨트롤러에서 사용

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    @GetMapping("/custom-convert")
    public String customConvert(@RequestParam("value") CustomType customType) {
        return "Converted Value: " + customType.getValue();
    }
}

입력 요청:

GET /custom-convert?value=test

결과:

Converted Value: test

스프링은 StringToCustomTypeConverter를 사용해 요청 파라미터 "test"를 CustomType 객체로 변환합니다.

4. TypeConverter 등록

스프링에서 커스텀 변환기를 등록하려면 **WebMvcConfigurer**를 사용합니다:

import org.springframework.context.annotation.Configuration;
import org.springframework.format.FormatterRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addConverter(new StringToCustomTypeConverter());
    }
}

5. TypeConverter와 관련된 컴포넌트

1. ConversionService:
   • 스프링의 타입 변환을 총괄하는 서비스.
   • TypeConverter를 등록하고 관리.
   • 기본 구현: DefaultConversionService.
2. FormatterRegistry:
   • 변환기와 포맷터를 등록하는 레지스트리.
3. Converter:
   • TypeConverter의 구체적인 구현체로, 한 타입을 다른 타입으로 변환하는 로직을 작성.

6. 정리 표

항목 내용

7. 결론

• TypeConverter는 스프링에서 입력 데이터(문자열 등)를 원하는 타입(Java 객체 등)으로 변환하거나, Java 객체를 특정 포맷(String 등)으로 변환하는 데 사용됩니다.
• 기본적으로 제공되는 변환 외에도, 사용자 정의 변환기를 등록해 스프링의 타입 변환 기능을 확장할 수 있습니다.
• REST API나 요청 파라미터의 데이터 처리 과정에서 매우 유용하며, 데이터 타입 변환을 간단하고 일관되게 관리할 수 있도록 도와줍니다.

ConversionService

• **ConversionService**는 스프링 프레임워크에서 제공하는 인터페이스로, 한 타입을 다른 타입으로 변환하는 데 사용됩니다.
• 이는 타입 변환을 중앙에서 관리하고, 통합된 방식으로 변환기를 사용할 수 있도록 도와줍니다.

1. ConversionService의 역할

• 타입 변환의 중심 역할:
  • Converter를 관리하고, 필요한 경우 적절한 변환기를 선택해 타입 변환을 수행합니다.
• 기본 제공 변환:
  • String ↔ Integer, String ↔ Boolean, String ↔ Date, String ↔ Enum 등.
• 커스텀 타입 변환:
  • 사용자 정의 타입 변환기를 등록해 특정 타입 간의 변환도 처리할 수 있습니다.

2. ConversionService의 구현체

• 스프링은 ConversionService 인터페이스를 구현한 기본 클래스들을 제공합니다:
  1. DefaultConversionService:
     • 스프링에서 제공하는 기본 변환 서비스.
     • 대부분의 변환 작업에 대해 기본 구현을 제공하며, 추가 변환기를 등록할 수도 있습니다.
  2. GenericConversionService:
     • 커스텀 변환기 등록을 지원하는 범용 변환 서비스.
  3. FormattingConversionService:
     • DefaultConversionService를 확장하며, 포맷터(Formatter)를 지원.

3. ConversionService 사용 방법

1) 기본 제공 변환

스프링은 DefaultConversionService를 통해 다양한 타입 변환을 기본 제공하며, 이를 직접 사용할 수 있습니다.

import org.springframework.core.convert.support.DefaultConversionService;
import org.springframework.core.convert.ConversionService;

public class Main {
    public static void main(String[] args) {
        // DefaultConversionService 생성
        ConversionService conversionService = new DefaultConversionService();

        // 기본 변환 사용
        int convertedInt = conversionService.convert("123", Integer.class);
        boolean convertedBool = conversionService.convert("true", Boolean.class);

        // 결과 출력
        System.out.println("Converted Integer: " + convertedInt); // 123
        System.out.println("Converted Boolean: " + convertedBool); // true
    }
}

2) 커스텀 변환기 등록

1. 커스텀 변환기 작성

import org.springframework.core.convert.converter.Converter;

// String -> CustomType 변환기
public class StringToCustomTypeConverter implements Converter<String, CustomType> {

    @Override
    public CustomType convert(String source) {
        return new CustomType(source);
    }
}

// CustomType 클래스
public class CustomType {
    private final String value;

    public CustomType(String value) {
        this.value = value;
    }

    public String getValue() {
        return value;
    }
}

2. Custom ConversionService 설정

import org.springframework.core.convert.support.GenericConversionService;

public class Main {
    public static void main(String[] args) {
        // ConversionService 생성
        GenericConversionService conversionService = new GenericConversionService();

        // 커스텀 변환기 등록
        conversionService.addConverter(new StringToCustomTypeConverter());

        // 변환 수행
        CustomType customType = conversionService.convert("test-value", CustomType.class);

        // 결과 출력
        System.out.println("Converted CustomType Value: " + customType.getValue());
    }
}

4. ConversionService와 FormatterRegistry

• **ConversionService**는 변환기(Converter)를 관리하며, 타입 변환을 처리합니다.
• **FormatterRegistry**는 포맷터(Formatter)를 지원하며, ConversionService의 확장된 형태로 볼 수 있습니다.
• WebMvcConfigurer에서 FormatterRegistry를 사용하여 변환기나 포맷터를 등록할 수 있습니다.

변환기 등록

import org.springframework.context.annotation.Configuration;
import org.springframework.format.FormatterRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addConverter(new StringToCustomTypeConverter());
    }
}

5. ConversionService와 Spring MVC의 관계

Spring MVC에서의 ConversionService 동작

• 입력 요청 처리:
  • HTTP 요청 파라미터를 컨트롤러 메서드의 매개변수로 매핑할 때 사용.
  • 예: "123" → Integer.
• 출력 응답 처리:
  • 컨트롤러 메서드의 반환값을 클라이언트로 전송할 데이터 형식으로 변환.
  • 예: Java 객체 → String.

6. 주요 메서드

7. 정리

8. 결론

• **ConversionService**는 스프링에서 타입 변환을 통합적으로 관리하는 강력한 도구입니다.
• 기본 제공 변환기 외에도, 사용자 정의 변환기를 등록해 커스텀 타입 간의 변환을 처리할 수 있습니다.
• HTTP 요청, 응답, 빈 설정 등 다양한 상황에서 일관된 방식으로 타입 변환을 처리하여 개발자의 부담을 줄이고 코드의 유지보수성을 높입니다.

Formatter

• Formatter는 스프링에서 제공하는 인터페이스로, 문자열(String)을 특정 객체로 변환하거나, 객체를 문자열로 변환하는 데 사용됩니다.
• 특히, **지역화(Localization)**를 지원하여 날짜, 숫자 등의 데이터 포맷팅과 같은 작업에 적합합니다.

1. Formatter의 역할

1. 문자열 → 객체 변환:
   • 사용자가 입력한 문자열 데이터를 특정 Java 객체로 변환.
   • 예: "2025-01-01" → LocalDate.
2. 객체 → 문자열 변환:
   • Java 객체를 특정 형식의 문자열로 변환하여 사용자에게 출력.
   • 예: LocalDate.of(2025, 1, 1) → "2025-01-01".
3. 지역화(Localization):
   • 포맷팅 작업 시, Locale을 고려하여 데이터를 변환.

2. Formatter와 Converter의 차이점

3. Formatter와 ConversionService의 관계

• **ConversionService**는 다양한 타입 간의 변환을 관리하는 중심 인터페이스입니다.
• Formatter는 **FormattingConversionService**에 등록되어 동작하며, 주로 사용자 입력값의 포맷팅 작업을 처리합니다.
• 즉, Formatter는 ConversionService의 한 부분으로, 특정 포맷의 데이터를 처리할 때 사용됩니다.

4. Formatter 사용 방법

1) Formatter 구현

import org.springframework.format.Formatter;

import java.text.ParseException;
import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import java.util.Locale;

public class LocalDateFormatter implements Formatter<LocalDate> {

    private static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd");

    @Override
    public LocalDate parse(String text, Locale locale) throws ParseException {
        return LocalDate.parse(text, FORMATTER); // 문자열 → LocalDate 변환
    }

    @Override
    public String print(LocalDate object, Locale locale) {
        return object.format(FORMATTER); // LocalDate → 문자열 변환
    }
}

2) Formatter 등록

Formatter를 사용하려면 스프링의 WebMvcConfigurer 또는 FormattingConversionService에 등록해야 합니다.

import org.springframework.context.annotation.Configuration;
import org.springframework.format.FormatterRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addFormatter(new LocalDateFormatter()); // Formatter 등록
    }
}

3) 컨트롤러에서 사용

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import java.time.LocalDate;

@RestController
public class MyController {

    @GetMapping("/date")
    public String getDate(@RequestParam("date") LocalDate date) {
        return "Parsed Date: " + date;
    }
}

• 요청: /date?date=2025-01-01
• 응답: Parsed Date: 2025-01-01

5. 주요 메서드

6. 정리 표

7. Formatter와 Converter의 활용 예

8. 결론

• Formatter는 문자열과 객체 간의 변환에 특화된 도구로, 지역화(Localization)를 고려한 데이터 포맷팅에 사용됩니다.
• Converter는 더 일반적인 타입 간 변환을 처리하며, 지역화는 지원하지 않습니다.
• ConversionService는 Formatter와 Converter를 통합 관리하며, 다양한 변환 작업을 처리하는 중심 인터페이스 역할을 합니다.
• Formatter는 주로 날짜, 숫자, 통화와 같은 포맷된 데이터를 처리하는 데 적합하며, 사용자 입력값 변환과 출력 포맷팅 작업에서 유용합니다.

Spring 프로그래밍

Spring 웹 애플리케이션 계층 구조 (개발 구조, 만들 것들)

Maven & Gradle

Maven & Gradle 사용 상황 비교

주요 결론

• Maven은 단순성과 표준화를 추구하며, 간단한 프로젝트나 학습용으로 적합합니다.
• Gradle은 유연성과 속도를 중시하며, 대규모 프로젝트나 복잡한 빌드 작업에 유리합니다.

Spring Annotation

주요 어노테이션 분류

Lombok 어노테이션

Spring JPA 어노테이션

기타 어노테이션

장점과 주의점

[참고] 

Lombok

Slf4j와 Lombok의 로깅

@Controller vs @RestController

Spring MVC와 Lombok의 활용

결론

• Lombok은 코드 간소화와 가독성 향상에 특화된 Java 라이브러리로, Spring MVC와 결합 시 생산성을 극대화합니다.
• Slf4j와 Logback은 로깅 관리에서 핵심적인 역할을 하며, Lombok의 @Slf4j로 더욱 간단히 구현 가능합니다.
• @Controller는 뷰 기반 애플리케이션에, @RestController는 데이터 중심 RESTful API 개발에 적합합니다.

[주요 어노테이션 정리]

필터(Filter)

1. 필터란?

**필터(Filter)**는 클라이언트의 요청(request)와 서버의 응답(response) 사이에서 요청 처리 전/후에 특정 작업을 수행할 수 있는 기능을 제공합니다.
필터는 주로 HTTP 요청과 응답을 가로채어 조작하거나, 요청이 컨트롤러에 도달하기 전에 사전 작업을 수행하는 데 사용됩니다.

2. 필터의 주요 사용 사례

1. 인증 및 권한 검사:
   • 요청이 적합한 사용자로부터 왔는지 확인하거나, 요청의 권한을 검증.
2. 로깅 및 모니터링:
   • 요청 및 응답 데이터를 기록하여 애플리케이션의 동작을 추적.
3. 데이터 변환/압축:
   • 요청 데이터 변환 또는 응답 데이터 압축.
4. CORS 처리:
   • Cross-Origin Resource Sharing(CORS) 요청 처리.
5. 보안 작업:
   • CSRF(Cross-Site Request Forgery) 방지 토큰 검증, 헤더 조작 방지 등.

3. 필터의 특징

1. 서블릿 컨테이너에서 동작:
   • 필터는 서블릿 컨테이너(Servlet Container, 예: Tomcat)에서 관리됩니다.
   • 스프링이 제공하는 Filter 인터페이스는 서블릿 표준(javax.servlet.Filter)을 확장한 것입니다.
2. 전역적으로 동작:
   • 컨트롤러에 도달하기 전에 모든 요청/응답에 대해 동작합니다.
3. 체인 방식:
   • 여러 필터가 등록되어 있는 경우, 필터 체인(Filter Chain)을 통해 순서대로 실행됩니다.

4. 필터 구현 방법

1) 기본 필터 구현

javax.servlet.Filter 인터페이스를 구현하여 필터를 작성합니다.

import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import java.io.IOException;

// 모든 요청에 대해 필터 적용
@WebFilter("/*")
public class LoggingFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        // 초기화 작업 (필요 시 구현)
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // 요청 처리 전
        System.out.println("Request received at: " + request.getRemoteAddr());

        // 다음 필터 또는 서블릿 호출
        chain.doFilter(request, response);

        // 응답 처리 후
        System.out.println("Response processed");
    }

    @Override
    public void destroy() {
        // 리소스 해제 작업 (필요 시 구현)
    }
}

• doFilter 메서드:
  • 요청이 컨트롤러로 전달되기 전, 특정 작업을 수행합니다.
  • chain.doFilter(request, response)를 호출하여 다음 필터 또는 서블릿으로 요청을 전달합니다.
  • chain.doFilter 이후 코드는 응답이 생성된 후 실행됩니다.

2) 스프링 부트에서 필터 등록

스프링 부트에서는 @Bean을 사용해 필터를 등록할 수 있습니다.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import javax.servlet.Filter;

@Configuration
public class FilterConfig {

    @Bean
    public Filter loggingFilter() {
        return new LoggingFilter();
    }
}

5. 필터 체인(Filter Chain)

필터는 여러 개 등록될 수 있으며, 등록 순서에 따라 체인 방식으로 동작합니다.

• 필터가 호출될 때, FilterChain을 통해 다음 필터로 요청을 전달합니다.
• 최종적으로 컨트롤러나 서블릿에 도달하며, 응답은 필터 체인을 역순으로 통과합니다.

6. 필터의 실행 순서 지정

스프링 부트에서는 @Order 또는 FilterRegistrationBean을 사용해 필터의 실행 순서를 지정할 수 있습니다.

1) @Order로 순서 지정

import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;

@Component
@Order(1) // 낮은 숫자가 먼저 실행됨
public class FirstFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        System.out.println("First Filter - Before");
        chain.doFilter(request, response);
        System.out.println("First Filter - After");
    }
}

2) FilterRegistrationBean으로 순서 지정

import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class FilterConfig {

    @Bean
    public FilterRegistrationBean<LoggingFilter> loggingFilter() {
        FilterRegistrationBean<LoggingFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(new LoggingFilter());
        registrationBean.setOrder(2); // 순서 지정 (낮은 숫자가 먼저 실행)
        registrationBean.addUrlPatterns("/*"); // 필터를 적용할 URL 패턴
        return registrationBean;
    }
}

7. 예제: 인증 필터

JWT 인증 필터

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class JwtAuthFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        String authHeader = httpRequest.getHeader("Authorization");

        if (authHeader == null || !authHeader.startsWith("Bearer ")) {
            httpResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            httpResponse.getWriter().write("Unauthorized");
            return;
        }

        String token = authHeader.substring(7); // "Bearer " 이후의 토큰 추출
        if (!validateToken(token)) {
            httpResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            httpResponse.getWriter().write("Invalid token");
            return;
        }

        chain.doFilter(request, response); // 다음 필터로 요청 전달
    }

    private boolean validateToken(String token) {
        // 토큰 검증 로직 구현
        return "valid-token".equals(token);
    }
}

설정:

@Bean
public FilterRegistrationBean<JwtAuthFilter> jwtAuthFilter() {
    FilterRegistrationBean<JwtAuthFilter> registrationBean = new FilterRegistrationBean<>();
    registrationBean.setFilter(new JwtAuthFilter());
    registrationBean.addUrlPatterns("/secure/*"); // 특정 URL 패턴에만 적용
    registrationBean.setOrder(1);
    return registrationBean;
}

8. 정리

9. 결론

필터는 HTTP 요청과 응답을 처리하는 강력한 전처리/후처리 메커니즘으로, 인증, 로깅, 데이터 조작 등 다양한 작업을 수행할 수 있습니다.
스프링 부트에서는 간단한 설정으로 필터를 등록하고, 순서를 지정하여 유연하게 요청/응답 처리를 관리할 수 있습니다.
필터는 전역적으로 동작하기 때문에, 컨트롤러 단위보다 요청 흐름의 초기 단계에서 작업을 수행할 때 적합합니다.

API 예외처리

• API 예외처리는 클라이언트와 서버 간의 상호작용 중 발생할 수 있는 오류를 처리하고, 클라이언트에 일관된 오류 응답을 제공하기 위한 방법입니다.

1. API 예외처리의 목표

1. 일관성:
   • 클라이언트가 API의 오류를 쉽게 이해하고 처리할 수 있도록, 표준화된 형식의 오류 응답 제공.
2. 가독성:
   • 명확한 오류 메시지와 상태 코드 전달로 디버깅과 문제 해결을 간소화.
3. 보안:
   • 민감한 서버 내부 정보를 클라이언트에 노출하지 않음.

2. 기본적인 예외 처리 방식

1) @ExceptionHandler 사용

• 특정 컨트롤러에서 발생한 예외를 처리하기 위한 메서드를 지정합니다.
• 단일 컨트롤러 내에서 예외를 처리한 후
• 계층별로 알맞은 예외를 발생(throw new)시키기만 하면됩니다.

스프링 MVC에서 컨트롤러 단위로 예외를 처리할 수 있습니다.

import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.http.ResponseEntity;

@RestController
public class MyController {

    @GetMapping("/example")
    public String example() {
        if (true) {
            throw new IllegalArgumentException("Invalid input!");
        }
        return "Success";
    }

    // 특정 예외 처리
    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> handleIllegalArgumentException(IllegalArgumentException e) {
        return ResponseEntity.badRequest().body("Error: " + e.getMessage());
    }
}

결과:

• 요청: GET /example
• 응답: 
• { "error": "Error: Invalid input!" }

• 문제점
  1. Controller 코드에 Exception 처리를 위한 책임이 추가된다.(단일 책임 원칙 위반)
  2. 단일 컨트롤러 내의 예외만 처리가 가능하다.(컨트롤러 예외처리 중복코드)
  3. 코드 재사용, 유지보수성 부족

2) @ControllerAdvice 사용

@ControllerAdvice는 애플리케이션 전역에서 예외를 처리할 수 있도록 해줍니다.
컨트롤러마다 예외 처리 로직을 반복하지 않아도 됩니다.

import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> handleIllegalArgumentException(IllegalArgumentException e) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Error: " + e.getMessage());
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handleGeneralException(Exception e) {
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("Unexpected error occurred!");
    }
}

결과:

• 모든 컨트롤러에서 발생하는 예외를 처리할 수 있습니다.
• 예외마다 별도의 처리 로직을 정의할 수 있습니다.

3) ResponseEntityExceptionHandler 상속

스프링의 기본 예외 처리 기능을 확장하여 API 예외 처리를 커스터마이징할 수 있습니다.

import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.context.request.WebRequest;
import org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler;

@ControllerAdvice
public class CustomResponseEntityExceptionHandler extends ResponseEntityExceptionHandler {

    @Override
    protected ResponseEntity<Object> handleExceptionInternal(Exception ex, Object body,
                                                             HttpHeaders headers, HttpStatus status, WebRequest request) {
        return new ResponseEntity<>(new ErrorResponse("INTERNAL_ERROR", ex.getMessage()), status);
    }

    // 사용자 정의 예외 처리
    @ExceptionHandler(CustomException.class)
    public ResponseEntity<Object> handleCustomException(CustomException ex) {
        return new ResponseEntity<>(new ErrorResponse("CUSTOM_ERROR", ex.getMessage()), HttpStatus.BAD_REQUEST);
    }
}

class ErrorResponse {
    private String code;
    private String message;

    public ErrorResponse(String code, String message) {
        this.code = code;
        this.message = message;
    }

    // Getters and setters
}

3. 응답 형식 표준화

JSON 형식의 응답을 사용하여 클라이언트가 오류를 쉽게 이해하도록 일관된 구조를 제공합니다.

표준 오류 응답 예시

{
  "timestamp": "2025-01-01T12:34:56",
  "status": 400,
  "error": "Bad Request",
  "message": "Invalid input",
  "path": "/example"
}

오류 응답 데이터 클래스

import java.time.LocalDateTime;

public class ApiError {
    private LocalDateTime timestamp;
    private int status;
    private String error;
    private String message;
    private String path;

    public ApiError(int status, String error, String message, String path) {
        this.timestamp = LocalDateTime.now();
        this.status = status;
        this.error = error;
        this.message = message;
        this.path = path;
    }

    // Getters and setters
}

ControllerAdvice에서 응답 사용

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<ApiError> handleIllegalArgumentException(IllegalArgumentException e, WebRequest request) {
        ApiError error = new ApiError(
                HttpStatus.BAD_REQUEST.value(),
                "Bad Request",
                e.getMessage(),
                request.getDescription(false)
        );
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(error);
    }
}

4. RestController와 연동

• @RestController와 @ControllerAdvice를 함께 사용하면, REST API에서 발생하는 모든 예외를 처리할 수 있습니다.
• 모든 응답은 JSON 형식으로 변환됩니다.

5. 정리 표

6. 결론

• API 예외 처리는 클라이언트와의 통신에서 중요한 요소로, 오류가 발생했을 때 클라이언트가 이를 쉽게 이해하고 적절히 처리할 수 있도록 돕습니다.
• 스프링에서는 @ControllerAdvice, @ExceptionHandler, ResponseEntityExceptionHandler와 같은 도구를 제공하여 효과적으로 예외를 처리하고, 응답을 일관되게 관리할 수 있습니다.
• 표준화된 JSON 응답 형식을 사용하면 클라이언트와 서버 간의 협업이 더 원활해집니다.

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

 🐳 

 🐳 

 🐳 

소제목 

🧩 부모 타입 변수 = 자식 타입 객체; 는 자동으로 부모 타입으로 변환이 일어납니다.

소제목 

🎵 클래스가 설계도라면 추상 클래스는 미완성된 설계도입니다.

의존관계 주입

📌 객체 간의 의존성을 스프링 컨테이너가 자동으로 관리하고 주입해주는 설계 패턴입니다. 객체가 다른 객체를 필요로 할 때, 직접 생성하지 않고 외부에서 주입받아 사용하도록 설계하는 방식입니다.

• @Autowired 는 의존성을 자동으로 주입할 때 사용하는 Annotation 이다.
  • 기본적으로 주입할 대상이 없으면 오류가 발생한다.(required = true)

의존관계 주입의 기본 개념

1. 의존성(Dependency):
   • A 객체가 B 객체를 사용해야 한다면, A는 B에 의존하고 있다고 말합니다.
   • 이때 B 객체를 A 내부에서 직접 생성하지 않고, 외부에서 주입받는 것을 의존관계 주입이라고 합니다.
2. 스프링 DI:
   • 스프링 컨테이너가 객체(빈)를 생성하고 관리하면서 필요한 의존성을 자동으로 주입합니다.
   • 개발자는 직접 의존성을 생성하거나 연결할 필요가 없으며, 컨테이너가 이를 처리합니다.

왜 의존성 주입인가?

@Autowired와 스프링 컨테이너가 있기 때문에, 개발자가 의존 객체를 직접 생성하지 않아도 되고, 컨테이너가 이를 대신 처리합니다. 이 점이 의존성 주입의 핵심입니다.

장점

1. 결합도 감소:
   • MyApp은 MyService의 구체적인 구현체를 몰라도 됩니다. (DIP 원칙 준수)
   • 다른 구현체로 변경할 때 코드 수정이 필요 없습니다.
2. 유연성 증가:
   • 스프링 컨테이너에서 주입받는 객체를 쉽게 교체하거나 확장할 수 있습니다.
3. 테스트 용이성:
   • 테스트 환경에서 Mock 객체를 주입할 수 있습니다.

1. 생성자 주입

• 생성자를 통해 의존성을 주입하는 방법.
• 최초에 한번 생성된 후 값이 수정되지 못한다.[불변, 필수]

public interface MyService {
    void doSomething();
}

// Spring Bean으로 등록
@Service
public class MyServiceImpl implements MyService {
    @Override
    public void doSomething() {
        System.out.println("MyServiceImpl 메서드 호출");
    }
}

// 생성자 주입 방식
@Component
public class MyApp {
		// 필드에 final 키워드 필수! 무조건 값이 있도록 만들어준다.(필수)
    private final MyService myService;

		// 생성자를 통해 의존성 주입, 생략 가능
    @Autowired
    public MyApp(MyService myService) {
        this.myService = myService;
    }

    public void run() {
        myService.doSomething();
    }
    
}

@ComponentScan(basePackages = "com.example.springdependency.test")
public class Main {
    public static void main(String[] args) {

        ApplicationContext context = new AnnotationConfigApplicationContext(Main.class);

        // 등록된 MyApp 빈 가져오기
        MyApp myApp = context.getBean(MyApp.class);

        // 빈 메서드 호출
        myApp.run();
    }
}

-------------------------------------

// 생성자가 두개인 경우 생략이 불가능하다.
@Component
public class MyApp {
		// 필드에 final 키워드 필수! 무조건 값이 있도록 만들어준다.(필수)
    private final MyService myService;
    
    public MyApp(MyService myService, String myRepository) {
        this.myService = myService;
    }

		// 생성자를 통해 의존성 주입
    // @Autowired를 생략하기 위해서는 생성자가 하나여야 한다.
    public MyApp(MyService myService) {
        this.myService = myService;
    }

    public void run() {
        service.doSomething();
    }
    
}

• 생성자가 하나인 경우 @Autowired 생략이 가능하다.
• 둘중 어떤 생성자를 사용해야 하는지 Spring은 알지 못한다.

2. Setter 주입

• Setter 메서드를 통해 의존성을 주입하는 방법.

@Component
public class MyApp {

    private MyService myService;

    // Setter 주입
    @Autowired
    public void setMyService(MyService myService) {
        this.myService = myService;
    }
    
    public void run() {
        myService.doSomething();
    }

}

선택하거나, 변경 가능한 의존관계에 사용한다.(생성자 주입은 필수 값)

// MyService가 Spring Bean으로 등록되지 않은 경우에도 주입이 가능하다.
@Autowired(required = false)
public void setMyService(MyService myService) {
    this.myService = myService;
}

// 실행 도중 인스턴스를 바꾸고자 하는 경우
// setMyService(); 메서드를 외부에서 호출하면 된다.(이런 경우는 거의 없음)

3. 필드 주입

• 필드에 직접적으로 주입하는 방법 (가장 추천되지 않음).

@Component
public class MyApp {

    @Autowired
    private MyService myService;  // 필드에 직접 주입

    public void run() {
        myService.doSomething();
    }
    
}

• 코드는 간결하지만 Spring이 없으면 사용할 수 없다.
  • 사용하지 않아야 한다.

// Spring을 사용하지 않는 경우 실행이 불가능하다.
public class MainV2 {
    public static void main(String[] args) {
        MyApp myApp = new MyApp();
        myApp.run();
    }
}

• 외부에서 myService 값을 설정하거나 변경할 방법이 없다.
  • 결국 setter를 만들어야 한다.
• 순수 Java 코드로 사용할 수 없다. = 테스트 코드 작성이 힘들다.
• Application의 실행과 관계 없는 @SpringBootTest 테스트 코드나 Spring에서만 사용하는 @Configuration 같은 곳에서 주입할 때 주로 사용한다.

4. 일반 메서드 주입

• 생성자, setter 주입으로 대체가 가능하기 때문에 사용하지 않는다.

@Component
public class MyApp {

    private MyService myService;

    // 일반 메서드 주입
    @Autowired
    public void init(MyService myService) {
        this.myService = myService;
    }
    
    public void run() {
        myService.doSomething();
    }

}

생성자 주입

📌 과거 setter, 필드 주입도 사용했지만 현재는 DI를 가지고 있는 대부분의 Framework가 생성자 주입 방식을 권장한다.

생성자 주입을 선택하는 이유

• 불변(immutable)
  • 어떤 요리(Web Application)를 만들지 정해졌다면 이미 재료(Bean)와 의존 관계가 결정된다.
  • 객체를 생성할 때 최초 한번만 호출된다.(불변)
  • setter 주입을 사용하면 접근제어자가 public 으로 설정되어 누구나 수정할 수 있게된다.
• 실수 방지
  • 순수 Java 코드로 사용할 때(주로 테스트 코드) 생성자의 필드를 필수로 입력하도록 만들어준다.(NPE 방지)
  • 컴파일 시점에 오류를 발생 시킨다. 즉, 실행 전에 오류를 알 수 있다.

public class MyApp {
    private MyService myService;

    public MyApp() {
        this.myService = new MyService(); // 직접 생성
    }

    public void run() {
        myService.doSomething();
    }
}

---------------------------------------

@Component // 해당 어노테이션이 MyService 객체를 bean으로 만들어준다. 즉 스프링이 객체 MyService를 저장한다.
public class MyApp {
    private final MyService myService;

    @Autowired
    public MyApp(MyService myService) {
        this.myService = myService; // 외부에서 주입 (직접 선언이 아니라 스프링에 저장된 객체 사용)
    }

    public void run() {
        myService.doSomething();
    }
}

• 위 코드 참고
• @Autowired: 스프링 컨테이너가 MyService 타입의 빈을 찾아서 자동으로 주입합니다.
• MyApp은 MyService를 직접 생성하지 않습니다. 대신, 스프링 컨테이너가 제공한 인스턴스를 사용합니다.

Spring Framework에 의존하지 않아도 객체 지향 특성을 가장 잘 사용하는 방법이다.

@RequiredArgsConstructor

📌 실제 Web Application을 개발하면 대부분이 불변 객체이고 생성자 주입 방식을 선택하게 된다. 이런 반복되는 코드를 편안하게 작성하기 위해 Lombok에서 제공하는 Annotation 이다.

@RequiredArgsConstructor

• final 필드를 모아서 생성자를 자동으로 만들어 주는 역할
• Annotation Processor 가 동작하며 컴파일 시점에 자동으로 생성자 코드를 만들어준다.
• 사용 방법

@Component
@RequiredArgsConstructor
public class MyApp {
		// 필드에 final 키워드 필수! 무조건 값이 있도록 만들어준다.(필수)
    private final MyService myService;
    
    // Annotation Processor가 만들어 주는 코드
    // public MyApp(MyService myService) {
    //     this.myService = myService;
    // }

    public void run() {
        myService.doSomething();
    }
    
}

• 만약 생성자가 필요한 경우가 생긴다면, 생성자 주입 방식을 직접 선언하면 된다.

@ComponentScan

📌 Spring이 특정 패키지 내에서 @Component, @Service, @Repository, @Controller 같은 Annotation이 붙은 클래스를 자동으로 검색하고, 이를 Bean으로 등록하는 기능이다. 개발자가 Bean을 직접 등록하지 않고도 Spring이 자동으로 관리할 객체들을 찾는다.

ComponentScan의 역할

• Chef가 요리할 재료를 자동으로 식료품 저장고에서 찾아오는 과정, Chef는 스스로 필요한 재료를 찾아 요리에 사용한다.

• 요리사(개발자)가 직접 재료(Bean)를 찾아서 가져올 필요가 없다.

@ComponentScan

1. 특정 패키지 내에 @Component Annotation이 붙은 클래스를 자동으로 찾아서 Spring Bean으로 등록한다.
   • Annotation을 이용해 Bean을 등록할 수 있어 코드가 간결해지고 유지보수가 쉬워진다.
2. 스캐닝 범위는 주로 애플리케이션의 루트(최상위) 패키지에서 시작된다.
3. @SpringBootApplication
   • 스프링 부트 애플리케이션의 시작점을 정의하기 위해 사용하는 애너테이션입니다. 이 애너테이션은 여러 기능을 결합한 복합 애너테이션으로, 스프링 부트 애플리케이션을 간단히 설정하고 실행할 수 있도록 돕습니다.
   • SpringBoot로 프로젝트를 생성하면 main() 메서드가 있는 클래스 상단에 @SpringBootApplication Annotation 이 존재한다.

@ComponentScan의 동작 순서

1. 스프링 컨테이너가 빈 등록

• Spring Application이 실행되면 @ComponentScan이 지정된 패키지를 탐색한다.
• @ComponentScan은 @Component, @Service, @Repository, @Controller 등의 애너테이션이 붙은 클래스를 탐색합니다.
• 해당 클래스들을 스프링 빈으로 등록합니다.
• 구현 클래스뿐만 아니라, 인터페이스와 그 구현체도 함께 빈으로 등록됩니다.

2. 의존성 정의 (인터페이스 기반 설계)

• 일반적으로 **인터페이스(추상화)**를 의존성으로 정의합니다.
  구현체는 스프링이 자동으로 선택하고 주입합니다.

3. 구현체 자동 연결

• 스프링은 등록된 빈 중에서 의존성으로 선언된 인터페이스에 맞는 구현체를 자동으로 찾아 주입합니다.
• 이 과정은 타입 매칭을 통해 이루어집니다.

@Configuration, @Bean

📌 Spring Bean을 등록하는 방법에는 수동, 자동 두가지가 존재한다.

Spring Bean 등록 방법

• Spring Bean은 Bean의 이름으로 등록된다.
  • 1. 자동 Bean 등록(@ComponentScan, @Component)
    • @Component 이 있는 클래스의 앞글자만 소문자로 변경하여 Bean 이름으로 등록한다.

// myService 라는 이름의 Spring Bean
@Component
public class MyService {

    public void doSomething() {
        System.out.println("Spring Bean 으로 동작");
    }
    
}

• @ComponentScan 을 통해 @Component로 설정된 클래스를 찾는다.

• 2. 수동 Bean 등록(@Configuration, @Bean)
  • @Configuration 이 있는 클래스를 Bean으로 등록하고 해당 클래스를 파싱해서 @Bean 이 있는 메서드를 찾아 Bean을 생성한다. 이때 해당 메서드의 이름으로 Bean의 이름이 설정된다.

// 인터페이스
public interface TestService {
    void doSomething();
}

// 인터페이스 구현체
public class TestServiceImpl implements TestService {
    @Override
    public void doSomething() {
        System.out.println("Test Service 메서드 호출");
    }
}

// 수동으로 빈 등록
@Configuration
public class AppConfig {
    
    // TestService 타입의 Spring Bean 등록
    @Bean
    public TestService testService() {
        // TestServiceImpl을 Bean으로 등록
        return new TestServiceImpl();
    }
    
}

// Spring Bean으로 등록이 되었는지 확인
public class MainApp {
    public static void main(String[] args) {
        // Spring ApplicationContext 생성 및 설정 클래스(AppConfig) 등록
        ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);

        // 등록된 TestService 빈 가져오기
        TestService service = context.getBean(TestService.class);

        // 빈 메서드 호출
        service.doSomething();
    }
}

Bean 충돌

📌 Bean 등록 방법에는 수동, 자동 두가지가 존재하고 Bean은 각각의 이름으로 생성된다. 이때 이름이 같은 Bean이 설정되고자 한다면 충돌이 발생한다.

같은 이름의 Bean 등록

• 자동 Bean 등록 VS 자동 Bean 등록

public interface ConflictService {
    void test();
}

// Bean의 이름을 service로 설정
@Component("service")
public class ConflictServiceV1 implements ConflictService {
    @Override
    public void test() {
        System.out.println("Conflict V1");
    }
}

// Bean의 이름을 service로 설정
@Component("service")
public class ConflictServiceV2 implements ConflictService {
    @Override
    public void test() {
        System.out.println("Conflict V2");
    }
}

// componentScan의 범위를 conflict 패키지 하위로 설정
@ComponentScan(basePackages = "com.example.springconcept.conflict")
public class ConflictApp {
    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext(ConflictApp.class);

        // Service 빈을 가져와서 실행
        ConflictService service = context.getBean(ConflictService.class);

        service.test();
    }
}

• ConflictingBeanDefinitionException 발생

수동 Bean 등록 VS 자동 Bean 등록

// conflictService 이름으로 Bean 생성
@Component
public class ConflictService implements MyService {
    @Override
    public void doSomething() {
        System.out.println("ConflictService 메서드 호출");
    }
}

public class ConflictServiceV2 implements MyService {
    @Override
    public void doSomething() {
        System.out.println("ConflictServiceV2 메서드 호출");
    }
}

// 수동으로 Bean 등록
@Configuration
public class ConflictAppConfig {
		
		// conflictService 이름으로 Bean 생성
    @Bean(name = "conflictService")
    MyService myService() {
        return new ConflictServiceV2();
    }

}

@ComponentScan(basePackages = "com.example.springconcept.conflict2")
public class ConflictApp2 {
    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext(ConflictApp2.class);

        // Service 빈을 가져와서 실행
        MyService service = context.getBean(MyService.class);

        service.doSomething();
    }
}

• 수동 Bean 등록이 자동 Bean 등록을 오버라이딩해서 우선권을 가진다.
• 의도한 결과라면 다행이지만, 아닌 경우(실수)가 대부분이다. → 버그 발생
• Spring Boot에서는 수동과 자동 Bean등록의 충돌이 발생하면 오류가 발생한다.

더보기

 

설정 변경(application.properties)

// 수동, 자동 Bean을 동시에 등록할 때 이름이 같으면 수동 Bean이 오버라이딩
spring.main.allow-bean-definition-overriding=true 

// 기본값
spring.main.allow-bean-definition-overriding=false

@Qualifier, @Primary

📌 같은 타입의 Bean이 중복된 경우 해결하기 위해 사용하는 Annotation

• 같은 타입의 Bean 충돌 해결 방법
  1. @Autowired + 필드명 사용
     • @Autowired 는 타입으로 먼저 주입을 시도하고 같은 타입의 Bean이 여러개라면 필드 이름 혹은 파라미터 이름으로 매칭한다.

public interface MyService { ... }

@Component
public class MyServiceImplV1 implements MyService { ... }

@Component
public class MyServiceImplV2 implements MyService { ... }

@Component
public class ConflictApp {

	// 필드명을 Bean 이름으로 설정
	@Autowired
	private MyService myServiceImplV2;
	...
}

1. @Qualifier 사용
   • Bean 등록 시 추가 구분자를 붙여 준다.
   • 생성자 주입, setter 주입 사용 가능

@Component
@Qualifier("firstService")
public class MyServiceImplV1 implements MyService { ... }

@Component
@Qualifier("secondService")
public class MyServiceImplV2 implements MyService { ... }

@Component
public class ConflictApp {

		private MyService myService;

		// 생성자 주입에 구분자 추가
		@Autowired
		public ConflictApp(@Qualifier("firstService") MyService myService) {
				this.myService = myService;
		}
	
		// setter 주입에 구분자 추가
		@Autowired
		public void setMyService(@Qualifier("firstService") MyService myService) {
				this.myService = myService;
		}
	...
}

1. @Primary 사용
   • @Primary로 지정된 Bean이 우선 순위를 가진다.

@Component
public class MyServiceImplV1 implements MyService { ... }

@Component
@Primary
public class MyServiceImplV2 implements MyService { ... }

@Component
public class ConflictApp {

		private MyService myService;

		@Autowired
		public ConflictApp(MyService myService) {
				this.myService = myService;
		}
	...
}

• 실제 적용 사례
  • Database가 (메인 MySQL, 보조 Oracle) 두개 존재하는 경우
    • 기본적으로 MySQL을 사용할 때 @Primary를 사용하면 된다.
    • 필요할 때 @Qualifier로 Oracle을 사용하도록 만들 수 있다.
    • 동시에 사용되는 경우 @Qualifier 의 우선순위가 높다.

수동 VS 자동

📌 Annotation 기반의 Spring에서는 자동 Bean 등록과 의존관계 주입을 사용하는 경우를 주로 사용한다. @Component 뿐만 아니라 @Controller, @Service, @Repository 등 자동으로 쉽게 등록할 수 있는 Annotation들을 지원하고 Spring Boot는 ComponentScan 방식을 기본으로 사용한다.

• 자동 Bean 등록을 사용하는 이유
  1. 다양한 Annotation으로 편리하게 등록할 수 있다.
  2. Spring Boot는 ComponentScan 방식을 기본으로 사용한다.
  3. 간단하지만 OCP, DIP를 준수하며 개발할 수 있다.
• 수동 Bean 등록을 사용하는 경우
  1. 외부 라이브러리나 객체를 Spring Bean으로 등록할 때
     • 외부 라이브러리에서 제공하는 클래스는 자동 등록이 불가능하다.
  2. 데이터베이스 연결과 같이 비지니스 로직을 지원하는 기술들에 사용한다.
     • 비지니스 로직보다 그 수가 아주 적지만 Application에 광범위하게 적용된다.
     • 설정 정보에 명시되어 있어서 유지보수성이 증가한다.
  3. 같은 타입의 Bean 여러개 중 하나를 명시적으로 선택해야 할 때

꼭 필요한 경우가 아니라면 자동 Bean 등록을 사용하면 된다.