잡학다식 개발일지

Spring Boot와 JPA

📌 Spring Boot는 JPA 설정을 자동으로 구성해 주어 JPA를 쉽게 사용할 수 있도록 도와준다. 기본적으로 필요한 EntityManagerFactory와 TransactionManager를 자동으로 설정하고 데이터베이스 관련 설정을 application.properties 파일에서 간단히 지정할 수 있게 해준다.

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

    // 트랜잭션 시작
    transaction.begin();

    try {
        // 비영속
        Tutor tutor = new Tutor(1L, "wonuk", 100);

        System.out.println("persist 전");
        // 영속
        em.persist(tutor);
        System.out.println("persist 후");

        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
    
    emf.close();

}

• 기존의 방식이다.
• 직접 트랜잭션을 사용한다.(JPA는 기본적으로 하나의 트랜잭션 안에서 기능을 수행한다)
• 직접 EntityManagerFactory 와 EntityManager 를 생성하여 사용한다.
• 직접 close() 하여 연결을 종료 해야한다.

Spring Boot와 JPA

• JPA는 Spring에 종속적인 것이 아니다.
• Spring Boot 에서 JPA를 사용하기 위해서는 build.gradle에 의존성 추가가 필요하다.
  • spring-boot-starter-data-jpa
  • 필요한 JPA 설정과 Entity 관리를 자동으로 해준다.
• 자동으로 내부에서 EntityManagerFactory 를 하나만 생성해서 관리(싱글톤)한다.
  • 자동으로 Bean으로 등록된다.
  • 직접 만들지 않아도 된다.
  • 직접 연결을 close() 하지 않아도 된다.
  • application.properties 에 설정된 DB 정보로 생성된다.
• @PersistenceContext를 통해 자동으로 생성된 EntityManager를 주입받아 사용할 수 있다.

@Repository
public class TutorRepository {
    
    @PersistenceContext
    private EntityManager em;

    public void save(Tutor tutor) {
        em.persist(tutor);
    }

    public Tutor findById(Long id) {
        return em.find(Tutor.class, id);
    }

    public List<Tutor> findAll() {
        return em.createQuery("SELECT * FROM tutor", Tutor.class).getResultList();
    }

    public void delete(Tutor tutor) {
        em.remove(tutor);
    }
}

• EntityManager 는 Spring Data JPA에서 관리하여 직접 관리하지 않아도된다.

Spring Data JPA

📌 Spring Data JPA는 Spring Framework에서 제공하는 모듈로 JPA를 쉽게 사용할 수 있도록 지원한다. 이를 통해 데이터베이스와 상호작용을 간편하게 구현할 수 있고 코드를 간소화할 수 있다.

Spring Data JPA 특징

1. JPA 추상화 Repository 제공
   • CrudRepository, JpaRepository 인터페이스를 제공한다.
   • SQL이나 EntityManager를 직접 호출하지 않아도 기본적인 CRUD 기능을 손쉽게 구현할 수 있다.
2. JPA 구현체와 통합
   • 일반적으로 Hibernate를 통해 자동으로 SQL이 생성된다.
3. QueryMethods
   • Method 이름만으로 SQL을 자동으로 생성한다.
   • @Query 를 사용하여 JPQL 또는 Native Query를 정의할 수 있다.
     • 복잡한 SQL을 직접 구현할 때 사용
4. 트랜잭션 관리와 LazyLoading
   • 트랜잭션 기능을 Spring과 통합하여 제공한다.
   • 연관된 Entity를 필요할 때 로딩하는 지연로딩 기능을 지원한다.

SimpleJpaRepository

📌 Spring Data JPA의 기본 Repository 구현체로 JpaRepository 인터페이스의 기본 메서드들을 실제로 수행하는 클래스이다. 내부적으로 EntityManager를 사용하여 JPA Entity를 DB에 CRUD 방식으로 저장하고 관리하는 기능을 제공한다.

• Spring Data JPA는 JpaRepository 인터페이스를 구현한 클래스를 자동으로 생성한다.
  • 기본적으로 SimpleJpaRepository를 구현체로 사용한다.

public interface MemberRepository extends JpaRepository<Member, Long> {
}

1. Repository를 interface로 선언한다.
2. JpaRepository<"@Entity 클래스", "@Id 데이터 타입"> 상속

• 내부동작
  • Spring이 실행되면서 JpaRepository 인터페이스를 상속받은 인터페이스가 있다면, 해당 인터페이스의 정보를 토대로 SimpleJpaRepository 를 생성하고 Bean으로 등록한다.
  • 인터페이스의 구현 클래스를 직접 만들지 않아도 JpaRepository 의 기능을 사용할 수 있다.
  • 개발자가 직접 SimpleJpaRepository를 사용하거나 참조할 필요는 없다.

• save() : 대상 Entity를 DB 테이블에 저장한다.
• findAll() : Entity에 해당하는 테이블의 모든 데이터를 조회한다.
• delete() : 대상 Entity를 데이터베이스에서 삭제한다.
• 이외에도 수많은 기능(Paging, Sorting 등)이 있다.

Query Methods

📌 Spring Data JPA에서 메서드 이름을 기반으로 데이터베이스 쿼리를 자동 생성하는 기능이다. 직접 SQL을 작성하지 않고도 복잡한 쿼리를 쉽게 수행할 수 있게된다.

• Spring Data JPA에서 메서드 이름을 기반으로 SQL을 자동으로 생성하는 기능
• JpaRepository는 findAll(), save()와 같은 기본적인 기능만 제공한다.
• 실제 Application 개발에는 상황에 따라 조건에 맞는 메서드가 필요하다.

public interface MemberRepository extends JpaRepository<Member, Long> {
		// Query Methods
    Member findByNameAndAddress(String name, String address);
}

// 자동으로 생성되어 실제로 실행되는 SQL
SELECT * FROM member WHERE name = ? AND address = ?;

• JpaRepository의 제네릭에 선언된 Entity와 매핑되는 테이블의 SQL이 생성된다.
• 개발자가 규칙에 맞게 메서드를 선언하면 SimpleJpaRepository에서 구현된다.
• 해석
  1. find : Entity에 매핑된 테이블(member)을 조회한다.
  2. ByName : 조건은 member 테이블의 name 필드이다.
  3. AndAddress : 또다른 조건은 member 테이블의 address 필드이다.

정답은 언제나 공식문서에 있다.

JPA Auditing

📌 엔티티의 생성 및 수정 시간을 자동으로 관리해주는 기능입니다. 이를 통해 개발자는 엔티티가 언제 생성되고 수정되었는지를 자동으로 추적할 수 있다.

모든 클래스에 생성 시간, 수정 시간 추가

@Entity
public class User {
		@Id
		private Long id;
		private String name;
		private String address;
		// 생성 시간
		private LocalDateTime createdAt;
		// 수정 시간
		private LocalDateTime updatedAt;
}

@Entity
public class Item {
		@Id
		private Long id;
		private String name;
		private String description;
		// 생성 시간
		private LocalDateTime createdAt;
		// 수정 시간
		private LocalDateTime updatedAt;
}

• 모든 Entity가 생성 시간, 수정 시간에 대한 연산을 수행해야 한다.
• JPA Auditing은 이러한 불편함을 해결해준다.
  • 개발자는 반복되는 불편함을 참지 않는다.

JPA Auditing 적용예시

@MappedSuperclass
public class BaseEntity{
		@Column(updatable = false)
		private LocalDateTime createdAt;
		private LocalDateTime updatedAt;

		@PrePersist
		public void prePersist(){
			LocalDateTime now = LocalDateTime.now();
			created_at = now;
			updated_at = now;
		}
	
		@PreUpdate
	  public void preUpdate() {
	    updated_at = LocalDateTime.now();
	  }
}

Spring Data JPA Auditing Annotation

• 적용하기

@EnableJpaAuditing

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

}

• Spring Data JPA에서 Auditing을 적용할 때 사용하는 어노테이션
• 일반적으로 Spring Boot를 실행하는 Application 클래스 상단에 선언한다.

• Spring Boot로 만들어진 프로젝트에 기본적으로 생성되는 Application 클래스

BaseEntity 생성

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class BaseEntity {

    @CreatedDate
    @Column(updatable = false)
    @Temporal(TemporalType.TIMESTAMP)
    private LocalDateTime createdAt;

    @LastModifiedDate
    @Temporal(TemporalType.TIMESTAMP)
    private LocalDateTime modifiedAt;
}

• updatable = false 설정으로 생성 시간이 수정되지 못하게 설정한다.

BaseEntity 상속

@Entity
public class User extends BaseEntity{
    @Id
    private Long id;
    private String name;
}

• createdAt, modifedAt 필드를 가지게 된다.
• 상속받는 것만으로 생성, 수정 시간을 자동으로 생성할 수 있다.

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 응답 형식을 사용하면 클라이언트와 서버 간의 협업이 더 원활해집니다.

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

 🐳 

 🐳 

 🐳 

소제목 

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

소제목 

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

아래의 사이트를 기반을 작성하였습니다.

다른 부분은 저번 과제의 연속이라 잘 해결이 되었지만,

package org.example.expert.config;

import com.fasterxml.jackson.databind.ObjectMapper;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;
import org.springframework.web.util.ContentCachingRequestWrapper;
import org.springframework.web.util.ContentCachingResponseWrapper;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;

import java.time.LocalDateTime;

@Slf4j
@Aspect
@Component
public class AdminAPILoggingAspect {

    private final ObjectMapper objectMapper;

    public AdminAPILoggingAspect(ObjectMapper objectMappers) {
        this.objectMapper = objectMappers;
    }

    @Around("execution(* org.example.expert.domain.comment.controller.CommentAdminController.*(..)) || " +
            "execution(* org.example.expert.domain.user.controller.UserAdminController.*(..))")
    public Object logAdminApiCall(ProceedingJoinPoint joinPoint) throws Throwable {
        // 요청 및 응답 정보 로깅
        HttpServletRequest request = getHttpServletRequest();
        HttpServletResponse response = getHttpServletResponse();

        ContentCachingRequestWrapper wrappedRequest = new ContentCachingRequestWrapper(request);
        ContentCachingResponseWrapper wrappedResponse = new ContentCachingResponseWrapper(response);

        // 요청 본문 로깅
        String requestBody = new String(wrappedRequest.getContentAsByteArray());
        log.info("Admin API Request: Time={}, URL={}, UserId={}, Body={}",
                LocalDateTime.now(), request.getRequestURI(), request.getHeader("User-Id"), requestBody);

        Object result = joinPoint.proceed(); // 실제 메서드 실행

        // 응답 본문 로깅
        String responseBody = new String(wrappedResponse.getContentAsByteArray());
        log.info("Admin API Response: Time={}, URL={}, UserId={}, Body={}",
                LocalDateTime.now(), request.getRequestURI(), request.getHeader("User-Id"), responseBody);

        wrappedResponse.copyBodyToResponse(); // 응답 본문을 클라이언트에 전달

        return result;
    }

    private HttpServletRequest getHttpServletRequest() {
        // HttpServletRequest 가져오는 로직
        return ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();
    }

    private HttpServletResponse getHttpServletResponse() {
        // HttpServletResponse 가져오는 로직
        return ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getResponse();
    }
}

현재 짰던 코드를 확인해 보았지만, 정확히는 파악이 안되어서 여러가지 찾아본 결과 나온 코드이다. 하지만 아직  정확하게는 판단이 안서서 하나하나 분석해 보려고 한다.

1. 클래스 정의

@Slf4j
@Aspect
@Component
public class AdminAPILoggingAspect {

• @Slf4j: 로깅을 위해 사용하는 Lombok 애노테이션. log.info, log.error 같은 로깅 메서드를 제공.
• @Aspect: 이 클래스가 AOP 역할을 수행하는 클래스라는 의미.
• @Component: Spring이 이 클래스를 Bean으로 관리

2. 생성자

public AdminAPILoggingAspect(ObjectMapper objectMappers) {
    this.objectMapper = objectMappers;
}

• ObjectMapper: JSON 처리를 위한 Jackson 라이브러리 객체야. 요청이나 응답 본문을 JSON으로 직렬화하거나 역직렬화할 때 사용.

3. AOP 핵심: @Around

@Around("execution(* org.example.expert.domain.comment.controller.CommentAdminController.*(..)) || " +
        "execution(* org.example.expert.domain.user.controller.UserAdminController.*(..))")
public Object logAdminApiCall(ProceedingJoinPoint joinPoint) throws Throwable {

• @Around: 특정 메서드 실행 전후에 로직을 실행하도록 설정.
• 여기서는 CommentAdminController와 UserAdminController 클래스의 모든 메서드에 AOP를 적용
• ProceedingJoinPoint joinPoint: 실제 대상 메서드를 호출할 수 있는 객체. AOP 적용 메서드 전후로 추가 로직을 실행 가능.

4. 요청 및 응답 객체 가져오기

HttpServletRequest request = getHttpServletRequest();
HttpServletResponse response = getHttpServletResponse();

• 현재 요청과 응답 객체를 가져오는 거야. getHttpServletRequest()와 getHttpServletResponse()는 아래에서 따로 정의돼 있음.

5. 요청 로깅

ContentCachingRequestWrapper wrappedRequest = new ContentCachingRequestWrapper(request);
String requestBody = new String(wrappedRequest.getContentAsByteArray());
log.info("Admin API Request: Time={}, URL={}, UserId={}, Body={}",
        LocalDateTime.now(), request.getRequestURI(), request.getHeader("User-Id"), requestBody);

• 요청 본문(Body)을 읽기 위해 ContentCachingRequestWrapper를 사용.
• getContentAsByteArray()로 요청 데이터를 가져온 뒤 로그로 출력.
• 로그에 포함된 정보:
  • 요청 시간 (LocalDateTime.now()).
  • 요청 URL (request.getRequestURI()).
  • 요청자 ID (request.getHeader("User-Id")).
  • 요청 본문 내용 (requestBody).

6. 대상 메서드 실행

Object result = joinPoint.proceed();

• AOP가 적용된 원래 메서드를 실행.
• 여기선 CommentAdminController나 UserAdminController의 메서드가 실행됨.

7. 응답 로깅

ContentCachingResponseWrapper wrappedResponse = new ContentCachingResponseWrapper(response);
String responseBody = new String(wrappedResponse.getContentAsByteArray());
log.info("Admin API Response: Time={}, URL={}, UserId={}, Body={}",
        LocalDateTime.now(), request.getRequestURI(), request.getHeader("User-Id"), responseBody);

• 응답 본문을 로깅. ContentCachingResponseWrapper로 응답 데이터를 읽음.
• 로그에 포함된 정보:
  • 응답 시간.
  • 요청 URL.
  • 요청자 ID.
  • 응답 본문 내용.

8. 응답 복원

wrappedResponse.copyBodyToResponse();

• ContentCachingResponseWrapper가 데이터를 읽으면 스트림이 닫히기 때문에, 복원해서 클라이언트에 다시 보냄.

9. 요청/응답 객체 가져오기

private HttpServletRequest getHttpServletRequest() {
    return ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();
}

private HttpServletResponse getHttpServletResponse() {
    return ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getResponse();
}

• RequestContextHolder를 사용해서 현재 요청(Request)과 응답(Response) 객체를 가져옴
• AOP는 컨트롤러 메서드 앞뒤에서 동작하니까, 여기서 현재 요청 정보를 얻음

코드 전체 흐름

1. 특정 관리자 API가 호출되면, AOP가 작동.
2. 요청 정보를 가져와서 로깅.
3. 원래 메서드를 실행 (joinPoint.proceed()).
4. 응답 정보를 로깅.
5. 요청과 응답 모두 클라이언트로 전달.

단방향

📌 단방향 연관관계는 객체 간의 관계가 한쪽에서만 참조 = 일방통행될 수 있는 관계를 말한다. 설정이 단순하고 유지 관리가 쉬우며 불필요한 데이터 접근을 방지할 수 있다.

데이터베이스 중심 객체 설계

• FK 값은 Tutor가 가지고 있다.
  • Tutor만 참조할 수 있다.
  • N:1, 다대일 연관관계, 가장 많이 사용된다.
  • 여러명(N)의 Tutor가 어떤 Company(1)에 소속 되어있는지 설정할 수 있다.

@Entity
@Table(name = "tutor")
public class Tutor {
		@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
		private Long id;
		
		private String name;
		
		@Column(name = company_id)
		private Long companyId;
		
		// 기본 생성자, getter/setter
}

@Entity
@Table(name = "company")
public class Company {
		@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
		private Long id;
		
		private String name;
		
		// 기본 생성자, getter/setter
}

// Company 생성 및 persist
Company company = new Company("sparta");
em.persist(company);

// Tutor 생성, setCompanyId, persist
Tutor tutor = new Tutor("wonuk");
tutor.setCompanyId(company.getId());
em.persist(tutor);

// IDENTITY 전략을 사용하면 persist()이후 PK를 바로 조회할 수 있다.
Tutor findTutor = em.find(Tutor.class, tutor.getId());

// 조회한 Tutor의 CompanyId로 Company 조회
Long companyId = findTutor.getCompanyId();
Company findCompany = em.find(Company.class, companyId);

• 객체 지향적인 코드를 작성할 수 없다.
• Java Collection을 사용하는 것처럼 tutor.getCompany() 를 사용하지 못한다.

객체 지향 객체 설계

• 객체는 다른 객체를 참조한다.
• N:1 관계는 @ManyToOne, @JoinColumn을 사용한다.
• 코드예시

@Entity
@Table(name = "tutor")
public class Tutor {
		@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
		private Long id;
		
		private String name;
		// N:1 단방향 연관관계 설정
		@ManyToOne
		@JoinColumn(name = "company_id")
		private Company company;
		
		// 기본 생성자, getter/setter
}

// Company 생성 및 persist
Company company = new Company("sparta");
em.persist(company);

// Tutor 생성, setCompany, persist
Tutor tutor = new Tutor("wonuk");
tutor.setCompany(company);
em.persist(tutor);

// IDENTITY 전략을 사용하면 persist()이후 PK를 바로 조회할 수 있다.
Tutor findTutor = em.find(Tutor.class, tutor.getId());

// 조회한 Tutor의 Company 조회
Company findCompany = findTutor.getCompany();

• Tutor의 FK와 Company의 PK를 @JoinColumn으로 매핑한다.
• Java Collection을 사용하는 것처럼 tutor.getCompany() 를 사용할 수 있다.

양방향

📌 양방향 연관관계는 객체 간의 관계가 양쪽에서 서로를 참조할 수 있는 관계를 의미한다. 이를 통해 양쪽에서 데이터를 쉽게 접근할 수 있지만 관계를 관리할 때 한쪽에서만 연관관계를 설정하거나 삭제하지 않도록 주의가 필요하다.

• 테이블에 변화는 없다.
  • Tutor 테이블의 FK로 Company 테이블에 JOIN
  • Company 테이블의 PK로 Tutor 테이블에 JOIN
• 사실상 테이블의 연관관계에는 방향의 개념이 없다.

@Entity
@Table(name = "tutor")
public class Tutor {
		@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
		private Long id;
		
		private String name;
		// N:1 단방향 연관관계 설정
		@ManyToOne
		@JoinColumn(name = "company_id")
		private Company company;
		
		// 기본 생성자, getter/setter
}

@Entity
@Table(name = "company")
public class Company {
		@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
		private Long id;
		
		private String name;
		
		// null을 방지하기 위해 ArrayList로 초기화 한다.(관례)
		@OneToMany(mappedBy = "company")
		private List<Tutor> tutors = new ArrayList<>();
		
		// 기본 생성자, getter/setter
}

• 양방향 연관관계 설정을 위해 mappedBy 속성을 설정한다.
  • Tutor의 company 필드와 매핑된다.

// Company 생성 및 persist
Company company = new Company("sparta");
em.persist(company);

// Tutor 생성, setCompany, persist
Tutor tutor = new Tutor("wonuk");
tutor.setCompany(company);
em.persist(tutor);

// IDENTITY 전략을 사용하면 persist()이후 PK를 바로 조회할 수 있다.
Tutor findTutor = em.find(Tutor.class, tutor.getId());

// 조회한 Tutor의 Company 조회
Company findCompany = findTutor.getCompany();

// Company에 속한 Tutor List 조회
List<Tutor> tutors = findCompany.getTutors();

• 반대 방향으로 객체 그래프를 탐색할 수 있다.

양방향 연관관계의 주인

📌 mappedBy는 JPA 양방향 연관관계 설정 시 사용되는 속성으로 두 엔티티 간의 관계에서 연관관계의 주인이 아닌 쪽에 선언한다. 이를 통해 외래 키 관리 책임을 주인 엔티티에 두고 매핑이 중복되지 않도록 한다.

테이블 연관관계

• Tutor ↔ Company (양방향)
• 테이블은 방향이 없다

객체 연관관계

• Tutor → Company N:1 연관관계 (단방향)
• Company → Tutor 1:N 연관관계 (단방향)
• 객체 연관관계는 결국 단방향 연관관계 두개로 양방향이 설정된다.

양방향 연관관계의 주인

1. Tutor의 Company를 수정할 때 FK가 수정
2. Company의 Tutor를 수정할 때 FK가 수정

• Tutor가 새로운 Company를 간다면?
  • Tutor의 참조값 Company 수정
  • Company의 참조값 List tutors 수정
  • DB 입장에서는 FK만 수정되면 된다. = mappedBy가 없는 쪽이 수정되면 된다.
• 결국, 둘 중 하나로만 외래 키를 관리해야 한다.

• 연관관계의 주인 선정 기준
  • 항상 FK가 있는 곳을 연관관계의 주인으로 지정한다.
  • Company가 주인인 경우
    • Company를 수정할 때 Tutor를 Update하는 SQL이 실행
    • 두번의 SQL이 실행되어야 한다. 혼동되기 쉽다.

Entity

📌 클래스에 @Entity가 있다면 JPA가 관리하는 Entity로 만들어진다.

• db 테이블 매핑되는 자바 객체

persistence.xml

📌 JPA 관련 설정

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.2"
             xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd">
    <persistence-unit name="test"> <!-- createEntityManagerFactory에서 사용할 이름 -->
        <class>org.entity.Tutor</class>
        <properties>
            <property name="jakarta.persistence.jdbc.driver" value="com.mysql.cj.jdbc.Driver"/>
            <!-- DB 아이디 -->
            <property name="jakarta.persistence.jdbc.user" value="root"/>
            <!-- DB 비밀번호 -->
            <property name="jakarta.persistence.jdbc.password" value="1111"/>
            <!-- 스키마 -->
            <property name="jakarta.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/sparta"/> 
						<!-- 스키마 자동생성 속성 -->
            <property name="hibernate.hbm2ddl.auto" value="create" />
						
						<!-- Hibernate가 DB에 전송하는 DDL, DML SQL을 콘솔에 출력한다. -->
            <property name="hibernate.show_sql" value="true"/>
            <property name="hibernate.format_sql" value="true"/>
            <property name="hibernate.use_sql_comments" value="true"/>
            
            <!-- 한꺼번에 전송될 SQL 수량 설정 -->
<!--            <property name="hibernate.jdbc.batch_size" value="10"/>-->
        </properties>
    </persistence-unit>
	</persistence>

@Entity

@Entity(name = "Tutor") // 기본 값, name 속성은 생략하면 된다.
@Table(name = "tutor")
public class Tutor {

    // PK
    @Id
    private Long id;

    // 필드
    private String name;

    // 기본 생성자
    public Tutor() {
    }

    // 쉽게 사용하기 위해 생성자 추가
    public Tutor(Long id, String name) {
        this.id = id;
        this.name = name;
    }
}

• JPA를 사용하여 객체를 테이블과 매핑할 때 사용한다.(필수)
• PK 값이 필수이다.(@Id 사용)
• 기본 생성자가 필수이다.
• final, enum, interface, inner 클래스에는 사용할 수 없다.
• 필드에 final 키워드를 사용할 수 없다.
• 속성
  • name
    • Entity 이름 지정
    • 기본 값은 클래스 이름과 같다.
    • 혼동을 방지하기 위해 기본 값을 사용(생략)하면 된다.

@Table

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

• 속성
  • name
    • Entity와 매핑할 테이블 이름을 지정
    • 기본 값은 Entity 이름(Tutor)을 사용
  • catalog
    • 데이터베이스 catalog 매핑
  • schema
    • 데이터베이스 schema 매핑
  • uniqueConstraints
    • DDL 생성 시 유니크 제약 조건 설정

JPA 실행

public static void main(String[] args) {
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    EntityManager em = emf.createEntityManager();
    EntityTransaction transaction = em.getTransaction();

    transaction.begin();

    try {
            
        Tutor tutor = new Tutor(1L, "wonuk");
        em.persist(tutor);

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

hibearnate.hbm2ddl.auto

📌 SessionFactory가 생성될때 스키마 DDL을 db로 검증하고 내보내는 기능을 상황에 따라 다르게 설정할수 있도록 하는 프로퍼티

• SessionFactory  = 도메인 모델을 데이터베이스로 맵핑하는 thread-safe하고 immutable한 표현이다.
• JPA는 Application 로딩 시점에 DDL을 자동으로 생성하는 기능을 지원한다. 방언(dialect)을 사용하여 Entity Mapping만 하여도 데이터베이스에 맞는 적절한 DDL이 생성된다.
• 실무에서는 validate 혹은 none 을 사용하고 개발 단계에서는 상황에 맞게 사용하면 된다.

public class Main {
    public static void main(String[] args) {
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
        EntityManager em = emf.createEntityManager();
        EntityTransaction transaction = em.getTransaction();

        transaction.begin();

        try {

            Tutor tutor = new Tutor(1L, "wonuk");
            em.persist(tutor);

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

        emf.close();
    }
}

더보기

제약조건 설정

📌 테이블에 입력되는 데이터가 사용자가 원하는 조건을 만족하는 데이터만 입력되는 것을 보장하는 것

• JPA를 사용하면 DDL 생성 시 제약조건을 설정할 수 있다. 실행 로직과는 별개로 DDL 생성시에만 활용된다.

DDL 자동생성 제약조건 설정

1. @Column
   • unique : 유니크, 기본값 false
   • nullable : 필수 여부, 기본값 true
   • length : 길이

@Column(unique = true, length = 20, nullable = false)

1. @Table
   • uniqueConstraints : 유니크, 이름을 직접 설정할 수 있다.

@Table(uniqueConstraints = {@UniqueConstraints
				(
					name = "name_unique", 
					columnNames= {"name"}
				)
		}
)
// 클래스

필드 매핑

📌 JPA로 관리되는 클래스인 Entity의 필드는 테이블의 컬럼과 매핑된다.

@Entity
@Table(name = "board")
public class Board {
    @Id
    private Long id;

    // @Column을 사용하지 않아도 자동으로 매핑된다.
    private Integer view;

    // 객체 필드 이름과 DB 이름을 다르게 설정할 수 있다.
    @Column(name = "title")
    private String bigTitle;

    // DB에는 기본적으로 enum이 없다.
    @Enumerated(EnumType.STRING)
    private BoardType boardType;

    // VARCHAR()를 넘어서는 큰 용량의 문자열을 저장할 수 있다.
    @Column(columnDefinition = "longtext")
    private String contents;

    // 날짜 타입 DATE, TIME, TIMESTAMP를 사용할 수 있다.
    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate;

    @Temporal(TemporalType.TIMESTAMP)
    private Date lastModifiedDate;
    
    @Transient
    private int count;

    public Board() {
    }

}

사용되는 Annotation

@Column 속성

@Enumerated

• 기본 설정인 ORDINAL을 사용하면 0, 1 과 같은 순서가 저장된다.

@Temporal

기본 키

📌 JPA Entity를 생성할 때 기본키는 필수로 생성해야 한다.

• 사용되는 Annotation
  1. @Id
     • 수동 생성

Tutor tutor = new Tutor(1L, "wonuk");

1. @GeneratedValue
   • 자동 생성

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

PK 생성 전략

• 영속성 컨텍스트는 PK가 필수이다.
  • 가장 권장되는 방식은 Long Type의 기본 키를 사용하는 것
• strategy 속성
  • GenerationType
    1. IDENTITY : MySQL, PostgreSQL에서 사용, 데이터베이스가 PK 자동 생성
    2. SEQUENCE : Oracle에서 사용, @SequenceGenerator 와 함께 사용
    3. TABLE : 키 생성용 테이블을 사용, @TableGenerator 와 함께 사용
    4. AUTO : dialect에 따라 자동 지정, 기본값
       • MySQL이면 IDENTITY, Oracle이면 SEQUENCE 로 설정
• 실행 결과

영속성 컨텍스트(PersistenceContext)

📌 Entity 객체를 영속성 상태로 관리하는 일종의 캐시 역할을 하는 공간으로 여기에 저장된 Entity는 데이터베이스와 자동으로 동기화되며 같은 트랜잭션 내에서는 동일한 객체가 유지된다.

• 영속성 상태 = JPA(Java Persistence API)에서 **엔티티(Entity)**가 EntityManager에 의해 관리되는 상태

• 논리적인 개념
  • 눈에 보이지 않는 공간이 생긴다.
• Entity Manager 를 통해서 영속성 컨텍스트에 접근한다.
  • EntityManager.persist(entity);
• Entity(객체)를 영속성 컨텍스트에 영속(저장)한다.

Entity

📌 데이터베이스의 테이블과 매핑되는 Java 클래스를 의미합니다.

• 데이터베이스에서 Entity 저장할 수 있는 데이터의 집합을 의미한다.
• JPA에서 Entity란 데이터베이스의 테이블을 나타내는 클래스를 의미한다.

1. Entity의 특징

1. 데이터베이스 테이블과 매핑:
   • Entity는 데이터베이스 테이블과 1:1로 매핑됩니다.
   • Java 객체의 필드는 데이터베이스 테이블의 컬럼에 매핑됩니다.
2. 필수 어노테이션:
   • @Entity: 클래스를 Entity로 지정.
   • @Id: 기본 키(Primary Key)로 사용할 필드 지정.
3. 영속성 관리:
   • Entity는 EntityManager에 의해 영속성 상태가 관리됩니다.
4. POJO(Plain Old Java Object):
   • Entity는 일반 Java 클래스처럼 동작하며, 특별한 상속이나 인터페이스 구현 없이 단순히 JPA의 규약을 따릅니다.

2. Entity 클래스 생성 예제

1) 기본 구조

import jakarta.persistence.*;

@Entity // 이 클래스를 Entity로 지정
@Table(name = "users") // 데이터베이스 테이블 이름 지정
public class User {

    @Id // 기본 키 지정
    @GeneratedValue(strategy = GenerationType.IDENTITY) // 자동 증가 값
    private Long id;

    @Column(nullable = false) // 필수 컬럼 지정
    private String name;

    @Column(unique = true) // 유니크 제약 조건
    private String email;

    // 기본 생성자
    public User() {}

    // Getters and Setters
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

3. 주요 어노테이션

1) @Entity

• 클래스를 JPA Entity로 선언.
• 필수 어노테이션.

@Entity
public class Product {
    // 필드와 메서드 정의
}

2) @Table

• 매핑할 데이터베이스 테이블 이름을 지정.
• 생략 시 클래스 이름이 테이블 이름으로 사용.

@Table(name = "products")

3) @Id

• 기본 키(Primary Key)로 사용할 필드를 지정.

@Id
private Long id;

4) @GeneratedValue

• 기본 키의 값을 자동 생성.
• strategy 속성으로 생성 전략을 지정:
  • IDENTITY: 데이터베이스가 자동 증가 값을 제공.
  • SEQUENCE: JPA가 시퀀스를 사용해 기본 키 값 생성.
  • TABLE: 키 생성 테이블 사용.
  • AUTO: 데이터베이스에 맞는 전략을 자동 선택.

@GeneratedValue(strategy = GenerationType.IDENTITY)

5) @Column

• 테이블의 컬럼에 매핑.
• 속성:
  • name: 컬럼 이름 지정.
  • nullable: NULL 허용 여부.
  • unique: 유니크 제약 조건.
  • length: 문자열 길이 제한.

@Column(name = "user_name", nullable = false, length = 50)

6) @Transient

• 특정 필드를 데이터베이스에 매핑하지 않음.

@Transient
private String temporaryData;

4. Entity의 활용

1) 데이터 저장

persist() 메서드를 사용하여 데이터를 저장.

User user = new User();
user.setName("John");
user.setEmail("john@example.com");

EntityManager em = entityManagerFactory.createEntityManager();
em.getTransaction().begin();
em.persist(user); // INSERT 쿼리 실행
em.getTransaction().commit();

2) 데이터 조회

find() 메서드를 사용하여 기본 키를 기준으로 데이터를 조회.

User user = em.find(User.class, 1L); // SELECT 쿼리 실행
System.out.println(user.getName());

3) 데이터 수정

영속 상태의 엔티티를 변경하면 변경 사항이 자동으로 데이터베이스에 반영(Dirty Checking).

em.getTransaction().begin();
user.setName("Updated Name"); // Dirty Checking으로 UPDATE 실행
em.getTransaction().commit();

4) 데이터 삭제

remove() 메서드를 사용하여 엔티티를 삭제.

em.getTransaction().begin();
em.remove(user); // DELETE 쿼리 실행
em.getTransaction().commit();

5. Entity와 데이터베이스 간 매핑

1) 필드와 컬럼 매핑

• 엔티티 필드는 데이터베이스 컬럼에 매핑됩니다.

@Column(name = "user_email", nullable = false)
private String email;

2) 테이블 매핑

• 엔티티 클래스는 테이블과 매핑됩니다.

@Table(name = "users")
@Entity
public class User {
    @Id
    private Long id;
    @Column(nullable = false)
    private String name;
}

3) 관계 매핑

• JPA는 엔티티 간의 관계를 지원하며, 주요 관계 매핑 어노테이션:
  • @OneToOne
  • @OneToMany
  • @ManyToOne
  • @ManyToMany

예: @OneToMany 관계 매핑

@Entity
public class User {
    @Id
    @GeneratedValue
    private Long id;

    @OneToMany(mappedBy = "user")
    private List<Order> orders;
}

@Entity
public class Order {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "user_id")
    private User user;
}

6. Entity의 장점

1. 객체 지향 데이터 모델링:
   • 데이터베이스 테이블을 Java 객체로 매핑하여 객체 중심으로 설계 가능.
2. SQL 자동 생성:
   • Hibernate나 JPA가 적절한 SQL을 자동으로 생성.
3. 데이터베이스 독립성:
   • 엔티티를 작성할 때 데이터베이스에 의존하지 않음.
4. 생산성 향상:
   • 데이터 접근 코드 작성이 단순화되고 유지보수가 쉬움.

7. 주의사항

1. 기본 생성자 필수:
   • JPA는 리플렉션을 사용하므로 기본 생성자가 반드시 필요.
2. Serializable 구현 권장:
   • 엔티티는 종종 네트워크나 파일로 전달되므로 Serializable을 구현하는 것이 좋음.
3. Equals와 HashCode 재정의:
   • 엔티티를 컬렉션에서 사용할 경우, @Id 기반으로 equals()와 hashCode()를 재정의.

결론

Entity는 JPA의 핵심 요소로, 데이터베이스와의 상호작용을 객체 중심으로 단순화하고 효율적으로 설계할 수 있게 합니다. 올바른 매핑과 상태 관리를 통해 데이터베이스와 객체 간의 매끄러운 통신이 가능합니다. 추가적으로 관계 매핑이나 성능 최적화 방법에 대해 더 알고 싶다면 말씀해주세요!

Entity 생명주기

1. 비영속(new/transient)
   • 영속성 컨텍스트가 모르는 새로운 상태
   • 데이터베이스와 전혀 연관이 없는 객체
2. 영속(managed)
   • 영속성 컨텍스트에 저장되고 관리되고 있는 상태
   • 데이터베이스와 동기화되는 상태
3. 준영속(detached)
   • 영속성 컨텍스트에 저장되었다가 분리되어 더 이상 기억하지 않는 상태
4. 삭제(removed)
   • 영속성 컨텍스트에 의해 삭제로 표시된 상태
   • 트랜잭션이 끝나면 데이터베이스에서 제거

엔티티의 생명주기를 현실 세계의 사람과 행정 시스템에 비유해서 설명해 보겠습니다.

1. 비영속 상태 (New/Transient)

• 비유:
  • 새로 태어난 아기 같은 상태입니다.
  • 아직 주민등록도 되어 있지 않고, 정부 시스템(행정 시스템)과 아무 연관이 없습니다.
  • 단순히 메모리에만 존재하는 객체이며, 데이터베이스에 저장되지 않은 상태입니다.
• 예:

  User user = new User(); // 비영속 상태
  user.setName("John");
  user.setEmail("john@example.com");
  

  • User 객체는 만들어졌지만, 아직 데이터베이스와는 아무 관련이 없습니다.

2. 영속 상태 (Managed)

• 비유:
  • 주민등록이 완료된 상태입니다.
  • 행정 시스템(영속성 컨텍스트)에 등록되어 정부가 그 사람을 기억하고 관리합니다.
  • 만약 사람이 이사(데이터 변경)를 하면, 시스템에도 자동으로 반영됩니다. (자동 동기화)
• 특징:
  • 영속성 컨텍스트가 이 객체를 관리하며, 변경 사항이 자동으로 데이터베이스에 반영됩니다.
• 예:
  • em.persist(user)를 호출하면 영속성 컨텍스트가 user를 관리하기 시작합니다.
  • 이후 user.setName("Updated John")처럼 객체가 변경되면, 데이터베이스에도 자동으로 반영됩니다.

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

    // 트랜잭션 시작
    transaction.begin();

    try {
        // 비영속
        Tutor tutor = new Tutor(1L, "wonuk", 100);

        System.out.println("persist 전");
        // 영속
        em.persist(tutor);
        System.out.println("persist 후");

        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
    
    emf.close();

}

em.persist() 가 호출되며 영속 상태가 된다.

• persist 후 출력 이후에 SQL이 실행된다.
• 트랜잭션 Commit 시점에 SQL이 실행된다.

3. 준영속 상태 (Detached)

• 비유:
  • 주민등록이 말소된 상태입니다.
  • 한때 행정 시스템(영속성 컨텍스트)에 등록되었지만, 더 이상 관리되지 않습니다.
  • 이 사람의 정보가 행정 시스템과는 연관이 없으므로, 정보를 업데이트해도 정부 시스템에는 반영되지 않습니다.
• 특징:
  • 객체는 메모리에 있지만, 영속성 컨텍스트와의 연결이 끊어져 데이터베이스와 동기화되지 않습니다.
• 예:
  • detach() 메서드는 객체를 영속성 컨텍스트에서 분리하여 준영속 상태로 만듭니다.
  • 객체를 변경해도 데이터베이스에 영향을 주지 않습니다.
  • 영속성 컨텍스트가 제공하는 기능을 사용하지 못한다.
  1. em.detach()
     • 특정 Entity만 준영속 상태로 변경한다.
  2. em.clear()
     • 영속성 컨텍스트를 초기화 한다.
  3. em.close()
     • 영속성 컨텍스트를 종료한다.

4. 삭제 상태 (Removed)

• 비유:
  • 사망신고를 한 상태입니다.
  • 행정 시스템(영속성 컨텍스트)에 의해 삭제로 표시되었으며, 트랜잭션이 완료되면 데이터베이스(정부 기록)에서도 완전히 삭제됩니다.
• 특징:
  • 삭제 상태로 표시되면, 트랜잭션이 완료되는 시점에 데이터베이스에서 삭제됩니다.
• 예:
  • remove() 메서드를 호출하면, 해당 객체는 삭제 상태로 표시되고, 트랜잭션이 끝나면 데이터베이스에서 제거됩니다.
• em.remove(user); // 삭제 상태로 전환

5. 전체 흐름을 비유로 설명

• 비영속 상태: "아직 주민등록이 안 된 상태의 아기"
  • 시스템(영속성 컨텍스트)과 전혀 연관이 없음.
• 영속 상태: "주민등록이 완료된 상태"
  • 정부가 해당 사람을 등록하고 관리.
  • 변경 사항(주소, 이름 등)이 자동으로 기록됨.
• 준영속 상태: "주민등록 말소 상태"
  • 과거에 등록되었지만 더 이상 정부 시스템에서 관리하지 않음.
  • 개인이 어디에 이사 가든 정부는 알 수 없음.
• 삭제 상태: "사망신고 상태"
  • 정부 시스템에 더 이상 존재하지 않으며, 기록에서 삭제될 예정.

6. 실제 코드 흐름 예제

// 비영속 상태
User user = new User();
user.setName("John");

// 영속 상태로 전환
EntityManager em = entityManagerFactory.createEntityManager();
em.getTransaction().begin();
em.persist(user); // 영속 상태
user.setName("Updated John"); // 변경 감지(Dirty Checking)

// 준영속 상태로 전환
em.detach(user);
user.setName("Detached John"); // 데이터베이스에 반영되지 않음

// 삭제 상태로 전환
em.getTransaction().begin();
em.remove(user); // 삭제 상태
em.getTransaction().commit(); // 데이터베이스에서 제거

7. 요약

1차 캐시

📌 엔티티를 영속성 컨텍스트에 저장할 때 생성되는 메모리 내 캐시이다. 엔티티는 먼저 1차 캐시에 저장되고 이후 같은 엔티티를 요청하면 DB를 조회하지 않고 1차 캐시에서 데이터를 반환하여 성능을 높일 수 있다.

• 영속성 컨텍스트의 1차 캐시에 저장된다.

// 비영속
Tutor tutor = new Tutor(1L, "wonuk", 100);

// 영속, 1차 캐시에 저장
em.persist(tutor);

• 영속된 Entity 조회

• Database가 아닌 1차 캐시에 저장된 Entity를 먼저 조회한다.

// 1차 캐시에서 조회
Tutor findTutor = em.find(Tutor.class, 1L);

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

    // 트랜잭션 시작
    transaction.begin();

    try {
        // 비영속
        Tutor tutor = new Tutor(1L, "wonuk", 100);

        // 영속
        System.out.println("persist 전");
        em.persist(tutor);
        System.out.println("persist 후");

        Tutor findTutor = em.find(Tutor.class, 1L);

        System.out.println("findTutor.getId() = " + findTutor.getId());
        System.out.println("findTutor.getName() = " + findTutor.getName());
        System.out.println("findTutor.getAge() = " + findTutor.getAge());

        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
    emf.close();
}

• 1차 캐시의 Entity를 조회한다.
  • 조회 SQL이 실행되지 않는다.
• 트랜잭션 Commit 시점에 INSERT SQL이 실행된다.

데이터베이스에 저장된 데이터 조회

• 1차 캐시는 동일한 트랜잭션 안에서만 사용이 가능하다.
• 요청이 들어오고 트랜잭션이 종료되면 영속성 컨텍스트는 삭제된다.
• 코드예시
  • xml <property name="hibernate.hbm2ddl.auto" value="none" /> 설정
    • DDL을 자동으로 생성하지 않는다.

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

    // 트랜잭션 시작
    transaction.begin();

    try {

        // 데이터베이스에서 조회 후 1차 캐시에 저장
        Tutor findTutor = em.find(Tutor.class, 1L);
        // 1차 캐시에서 조회
        Tutor findCacheTutor = em.find(Tutor.class, 1L);

        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
}

동일성 보장

📌 동일한 트랜잭션 안에서 특정 엔티티를 여러 번 조회해도 항상 같은 객체 인스턴스를 반환한다. 영속성 컨텍스트는 1차 캐시를 사용하여 같은 엔티티를 중복 조회해도 동일한 객체를 참조하게 하여 일관성을 유지한다.

• 동일한 트랜잭션 내에서 조회된 Entity는 같은 인스턴스를 반환한다.
• DB에 저장된 데이터를 조회하여 1차 캐시에 저장한다.
• 1차 캐시에 저장된 데이터를 조회한다.
• 코드예시

• Database에 저장된 데이터가 있는 상태

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

    // 트랜잭션 시작
    transaction.begin();

    try {

        // DB 조회, 1차 캐시에 저장
        Tutor findTutor1 = em.find(Tutor.class, 1L);
        // 1차 캐시 조회
        Tutor findTutor2 = em.find(Tutor.class, 1L);

        System.out.println("findTutor1 == findTutor2 : " + findTutor1.equals(findTutor2));

        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
    emf.close();
}

• 조회 SQL이 한번만 실행된다.
• 마치 Java Collection에서 객체를 조회하듯이 사용할 수 있다.

쓰기 지연

📌 엔티티 객체의 변경 사항을 DB에 바로 반영하지 않고 트랜잭션이 커밋될 때 한 번에 반영하는 방식으로 이를 통해 성능을 최적화하고 트랜잭션 내에서의 불필요한 DB 쓰기 작업을 최소화한다.

• 예시 코드
  • xml <property name="hibernate.hbm2ddl.auto" value="create" /> 설정
    • Entity와 매핑된 테이블을 삭제 후 새로 생성한다.
  • 코드예시

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

    // 트랜잭션 시작
    transaction.begin();

    try {
        System.out.println("트랜잭션 시작");
        Tutor tutor1 = new Tutor(1L, "wonuk1", 100);
        Tutor tutor2 = new Tutor(2L, "wonuk2", 200);

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

        System.out.println("트랜잭션 Commit 전");
        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
        System.out.println("트랜잭션 Commit 후");
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
    emf.close();
}

• 트랜잭션이 Commit된 이후에 SQL이 실행된다.
• 실행결과

• 여러개의 SQL을 하나씩 나누어 보낸다.
• hibernate.jdbc.batch_size
  • 여러개의 SQL을 여러번 보내는 것이 아니라 합쳐서 하나로 보낸다.
  • 통신 비용을 줄여서 성능을 개선할 수 있다.

변경 감지(Dirty Checking)

📌 영속성 컨텍스트가 엔티티의 초기 상태를 저장하고 트랜잭션 커밋 시점에 현재 상태와 비교해 변경 사항이 있는지 확인하는 기능이다.

• Database에 저장된 데이터가 있는 상태
• xml <property name="hibernate.hbm2ddl.auto" value="none" /> 설정

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

    // 트랜잭션 시작
    transaction.begin();

    try {
            
        Tutor tutor = em.find(Tutor.class, 1L);
        tutor.setName("수정된 이름");

        // Java Collection을 사용하면 값을 수정하고 다시 저장하지 않는다.
        // em.persist(tutor);

        System.out.println("트랜잭션 Commit 전");
        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
        System.out.println("트랜잭션 Commit 후");
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
    emf.close();
}

• em.persist(tutor); 로 저장하지 않아도 update SQL이 실행된다.
• Entity를 변경하고자 할 때 em.persist() 를 사용하지 않아야 실수를 방지한다.

flush

📌 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 기능으로, 변경된 엔티티 정보를 SQL로 변환해 데이터베이스에 동기화한다. 트랜잭션 커밋 시 자동으로 실행되지만 특정 시점에 데이터베이스 반영이 필요할 때 수동으로 호출할 수도 있다.

flush 사용 방법

1. 자동 호출
   • 트랜잭션이 Commit 되는 시점에 자동으로 호출된다.
2. 수동 호출
   • em.flush() 를 통해 수동으로 호출할 수 있다.

• 코드예시
  • xml <property name="hibernate.hbm2ddl.auto" value="create" /> 설정
    • 기존 테이블을 삭제(DROP) 후 다시 생성(CREATE)한다.

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

    // 트랜잭션 시작
    transaction.begin();

    try {

        Tutor tutor = new Tutor(1L, "wonuk", 100);
        em.persist(tutor);

        // flush 수동 호출
        em.flush();

        System.out.println("트랜잭션 Commit 전");
        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
    emf.close();
}

JPA

📌 객체 지향 프로그래밍 언어인 Java와 관계형 데이터베이스 간의 패러다임 불일치 문제를 해결하여 데이터베이스 작업을 객체 지향적으로 수행할 수 있도록 지원한다.

• 객체 지향적으로 설계하면 SQL코드가 점점 복잡해진다. JDBC로 외래키로 참조를 구현해본 경험이 있으니 뭔 말인지 잘 알것이다. 이러한 문제를 해결하기 위해 JPA가 등장했다.
• Java 애플리케이션에서 객체를 관계형 데이터베이스와 매핑하여 데이터를 처리할 수 있도록 지원하는 ORM(Object-Relational Mapping) 표준이다.

• 대표적인 구현체로 Hibernate를 주로 사용한다.
• 표준으로 만들어지면 더욱 명확하게 정의하고 사용할 수 있는 장점이 생긴다.

1. JPA의 주요 개념

1. ORM(Object-Relational Mapping):
   • 객체지향 프로그래밍의 객체와 관계형 데이터베이스의 테이블 간 매핑을 제공.
   • 예: Java 클래스의 필드 ↔ 데이터베이스 테이블의 컬럼.
2. Java EE 표준:
   • JPA는 Java EE 표준 사양으로, 특정 구현체(Hibernate, EclipseLink 등)에 독립적.
3. 추상화 제공:
   • SQL 작성 없이 데이터베이스 작업 가능.
   • JPA는 JPQL(Java Persistence Query Language)을 통해 객체 중심의 쿼리 제공.

2. JPA 주요 구성 요소

1. Entity:
   • 데이터베이스 테이블과 매핑되는 Java 클래스.
   • @Entity 어노테이션을 사용하여 매핑.

   @Entity
   public class User {
       @Id
       @GeneratedValue(strategy = GenerationType.IDENTITY)
       private Long id;
       private String name;
       private String email;
   
       // Getters and Setters
   }
   

2. EntityManager:
   • JPA의 핵심 인터페이스로, 엔티티를 관리.
   • 데이터베이스의 CRUD 작업을 처리.
   • 주요 메서드:
     • persist(): 엔티티 저장.
     • find(): 엔티티 조회.
     • merge(): 엔티티 갱신.
     • remove(): 엔티티 삭제.
3. Persistence Context:
   • 엔티티를 관리하는 메모리 공간.
   • 1차 캐시로 작동하여 같은 엔티티를 중복 조회할 때 데이터베이스를 재호출하지 않음.
4. JPQL:
   • JPA에서 사용하는 객체지향 쿼리 언어.
   • SQL과 유사하지만 엔티티와 속성을 대상으로 동작.

   String jpql = "SELECT u FROM User u WHERE u.name = :name";
   List<User> users = entityManager.createQuery(jpql, User.class)
                                   .setParameter("name", "John")
                                   .getResultList();
   

3. JPA의 동작 방식

1. 객체를 생성하고 저장:
   • EntityManager를 사용해 Java 객체를 데이터베이스에 저장.
   • SQL은 JPA가 자동 생성.

   EntityManager em = entityManagerFactory.createEntityManager();
   em.getTransaction().begin();
   
   User user = new User();
   user.setName("John");
   user.setEmail("john@example.com");
   
   em.persist(user); // INSERT SQL 생성 및 실행
   em.getTransaction().commit();
   

2. 데이터 읽기:
   • EntityManager의 find() 메서드를 사용해 데이터를 조회.
   • SQL은 자동 생성.

   User user = em.find(User.class, 1L); // SELECT SQL 생성 및 실행
   

3. 데이터 갱신:
   • 엔티티 객체의 속성을 변경하면 JPA가 자동으로 데이터베이스에 반영(Dirty Checking).

   em.getTransaction().begin();
   user.setEmail("newemail@example.com"); // UPDATE SQL 생성 및 실행
   em.getTransaction().commit();
   

4. 데이터 삭제:
   • remove() 메서드를 호출해 엔티티 삭제.

   em.getTransaction().begin();
   em.remove(user); // DELETE SQL 생성 및 실행
   em.getTransaction().commit();
   

4. JPA와 Hibernate의 관계

• JPA는 표준이고, Hibernate는 JPA의 구현체입니다.

• JPA를 사용하면 코드가 구현체에 종속되지 않으므로, 필요에 따라 Hibernate, EclipseLink 등을 교체 가능.
• Hibernate는 JPA 기능 외에도 고유한 추가 기능을 제공.

5. JPA의 장점

1. 생산성 향상:
   • SQL 작성이 줄어들고, 객체 중심으로 데이터를 처리.
2. 데이터베이스 독립성:
   • 애플리케이션 코드는 데이터베이스에 종속되지 않음.
3. 자동 관리:
   • 엔티티 상태(생성, 수정, 삭제 등)를 JPA가 관리.
4. JPQL 제공:
   • 객체 중심의 쿼리 언어로 개발자 친화적.
5. 캐싱:
   • 1차 캐시를 통해 불필요한 데이터베이스 호출을 최소화.

6. JPA의 단점

1. 학습 곡선:
   • JPA는 설정이 많고, 내부 동작 원리를 이해해야 효율적으로 사용할 수 있음.
2. 복잡한 쿼리:
   • JPQL은 복잡한 SQL(특히 여러 테이블의 JOIN) 작성 시 한계가 있음.
   • 이 경우 Native SQL을 사용해야 함.
3. 성능 최적화 필요:
   • N+1 문제, 캐싱 전략, 데이터베이스 스키마 설계 등을 제대로 관리하지 않으면 성능 문제가 발생.
4. 추가 오버헤드:
   • JPA가 SQL을 생성하고 실행하므로, 직접 SQL 작성보다 약간의 오버헤드 발생.

7. Spring Data JPA

Spring Data JPA는 JPA를 기반으로 한 스프링 프레임워크의 데이터 접근 계층 라이브러리로, JPA를 더욱 쉽게 사용할 수 있게 도와줍니다.

특징

• 기본 CRUD 메서드 자동 제공.
• 메서드 이름 기반 쿼리 생성.
• JPQL 및 Native SQL 지원.

예제: Repository 인터페이스 정의

public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByName(String name);
}

사용 예제

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;

    public List<User> getUsersByName(String name) {
        return userRepository.findByName(name);
    }
}

8. JPA와 다른 데이터 접근 방식 비교

항목 JPA MyBatis JDBC

9. JPA를 사용할 때 주의사항

1. N+1 문제:
   • 연관 관계에서 데이터가 예상보다 더 많이 로드될 수 있음.
   • 해결책: Fetch Join 또는 @BatchSize 사용.
2. 캐싱 전략 관리:
   • 1차 캐시와 2차 캐시 사용 시 일관성을 유지해야 함.
3. 데이터베이스 트랜잭션 관리:
   • JPA는 트랜잭션이 필요하므로 Spring과 함께 사용하는 경우 @Transactional로 트랜잭션 범위를 명시.
4. 복잡한 비즈니스 로직:
   • JPA만으로 모든 문제를 해결할 수 없으므로, 복잡한 쿼리는 Native Query 활용.

ORM(Object-Relational Mapping)

• 객체와 관계형 DB를 자동으로 Mapping하여 패러다임 불일치 문제를 해결한다.
• JDBC API

ORM(Object-Relational Mapping)

 🐳 객체 지향 프로그래밍의 객체와 관계형 데이터베이스의 테이블을 자동으로 매핑해주는 기술

1. ORM의 주요 개념

1. 객체-관계 불일치 해결:
   • 객체지향 언어에서는 데이터를 객체로 표현하지만, 관계형 데이터베이스는 데이터를 테이블로 저장.
   • ORM은 객체와 테이블 간의 매핑을 통해 이 불일치를 해결.
2. 자동화된 데이터 처리:
   • SQL 쿼리 작성 없이 객체를 사용하여 데이터 저장, 조회, 수정, 삭제를 처리.
3. 데이터베이스 독립성:
   • ORM을 사용하면 코드가 특정 데이터베이스에 종속되지 않음.

2. ORM의 주요 기능

1. CRUD 작업 자동화:
   • Create, Read, Update, Delete 작업을 객체를 통해 처리.
   • SQL 대신 메서드를 호출하여 데이터 조작.
2. 객체와 테이블 매핑:
   • 클래스 → 테이블, 필드 → 컬럼으로 매핑.
3. 연관 관계 매핑:
   • 객체의 연관 관계(1:1, 1:N, N:M)를 데이터베이스 테이블의 외래 키 관계로 매핑.
4. 캐싱 지원:
   • 1차 캐시(영속성 컨텍스트) 및 2차 캐시를 통해 데이터베이스 호출 최소화.
5. 쿼리 생성:
   • JPQL이나 Query DSL 등을 통해 객체 기반의 쿼리 작성 가능.

3. ORM의 장점

1. 생산성 증가:
   • SQL 쿼리를 작성하지 않아도 CRUD 작업을 수행 가능.
   • 데이터베이스 처리 로직의 코드 양을 크게 줄임.
2. 유지보수성 향상:
   • 객체 중심의 코드 작성으로 가독성이 높아지고, 데이터베이스 변경 시 코드 변경이 최소화.
3. 데이터베이스 독립성:
   • 코드가 특정 DBMS에 의존하지 않으므로 DB를 쉽게 교체 가능.
4. 보안 강화:
   • SQL 인젝션 같은 보안 취약점을 예방하기 쉬움.
5. 연관 관계 처리:
   • 객체 간의 관계를 직접 정의하고 활용 가능.

4. ORM의 단점

1. 학습 곡선:
   • ORM 도구의 설정 및 사용법을 이해하는 데 시간이 필요.
2. 성능 문제:
   • ORM이 자동 생성한 쿼리가 비효율적일 수 있음.
   • 복잡한 쿼리는 직접 작성해야 할 수도 있음(Native Query 사용).
3. 디버깅 어려움:
   • ORM이 생성한 SQL을 디버깅하거나 최적화하기 어렵다.
4. 추상화 한계:
   • 데이터베이스 고유 기능(예: 저장 프로시저, 특정 SQL 구문) 사용 시 어려움.

5. ORM 동작 방식

1) 매핑 설정

객체를 데이터베이스 테이블에 매핑.

• 클래스는 테이블에 매핑.
• 필드는 테이블의 컬럼에 매핑.

Java JPA 예제:

@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String name;

    @Column(unique = true, nullable = false)
    private String email;

    // Getters and Setters
}

2) 데이터 저장

객체를 데이터베이스에 저장하면, ORM이 INSERT 쿼리를 생성하고 실행.

User user = new User();
user.setName("John Doe");
user.setEmail("john@example.com");

entityManager.persist(user); // INSERT SQL 실행

3) 데이터 조회

객체를 조회하면 ORM이 자동으로 SELECT 쿼리를 생성.

User user = entityManager.find(User.class, 1L); // SELECT SQL 실행

6. JPA와 ORM의 관계

• JPA는 Java에서 ORM 표준을 정의한 API.
• Hibernate, EclipseLink 같은 구현체는 JPA의 표준을 따르며, 이를 기반으로 ORM 기능 제공.

7. ORM 사용 시 주의점

1. N+1 문제:
   • 연관된 데이터를 가져올 때 추가적인 쿼리가 반복 실행될 수 있음.
   • 해결책: Fetch Join, @BatchSize 사용.
2. 복잡한 쿼리:
   • 복잡한 JOIN 쿼리나 데이터베이스 고유 기능 사용 시 Native Query 작성 필요.
3. 캐싱 전략 관리:
   • 1차 캐시와 2차 캐시 사용을 적절히 조정해야 성능을 최적화.
4. 스키마 설계:
   • ORM은 데이터베이스 설계를 자동화하지 않으므로, 스키마 설계는 여전히 중요.

8. ORM이 적용된 데이터 처리 흐름

1. 애플리케이션 개발:
   • 개발자는 객체(Entity) 중심으로 코드를 작성.
2. ORM 매핑:
   • ORM이 객체와 테이블 간의 매핑을 수행.
3. 쿼리 생성 및 실행:
   • CRUD 작업 시 ORM이 SQL을 생성하여 데이터베이스와 통신.
4. 결과 매핑:
   • SQL 실행 결과를 객체로 변환하여 반환.

Java EE 표준

 🐳 Java를 사용하여 대규모 엔터프라이즈 애플리케이션을 개발하기 위한 표준 플랫폼입니다.

1. Java EE의 주요 개념

1. 표준화된 사양:
   • 엔터프라이즈 애플리케이션 개발을 위한 API와 스펙이 표준화되어 있어 다양한 구현체에서 동일하게 작동.
2. 컨테이너 기반 실행 환경:
   • Java EE 애플리케이션은 애플리케이션 서버(Java EE 컨테이너)에서 실행되며, 컨테이너가 리소스 관리, 보안, 트랜잭션 등을 처리.
3. 엔터프라이즈 개발 도구:
   • 데이터베이스 액세스, 메시징, 웹 서비스, 의존성 주입 등 대규모 애플리케이션에 필요한 기능 제공.

2. Java EE의 주요 구성 요소

1) Web Tier

• Servlet:
  • HTTP 요청/응답을 처리하는 자바 기반 웹 컴포넌트.
• JSP (Java Server Pages):
  • HTML과 Java 코드를 결합하여 동적인 웹 콘텐츠 생성.
• JSF (Java Server Faces):
  • MVC 패턴을 기반으로 한 컴포넌트 기반 UI 프레임워크.

2) Business Tier

• EJB (Enterprise JavaBeans):
  • 트랜잭션, 보안, 동시성 관리 등을 포함한 비즈니스 로직 실행.
• CDI (Contexts and Dependency Injection):
  • 의존성 주입(Dependency Injection)을 제공하여 객체 간의 결합도 감소.

3) Persistence Tier

• JPA (Java Persistence API):
  • ORM(Object Relational Mapping) 표준으로, 데이터베이스와 객체 간의 매핑을 제공.

4) Integration Tier

• JMS (Java Messaging Service):
  • 메시징 시스템과 통합을 지원.
• JAX-RS (Java API for RESTful Web Services):
  • RESTful 웹 서비스 개발을 위한 API.
• JAX-WS (Java API for XML Web Services):
  • SOAP 기반 웹 서비스 개발을 지원.

5) Other APIs

• JTA (Java Transaction API):
  • 분산 트랜잭션 관리.
• JavaMail:
  • 이메일 송수신 기능 제공.
• Batch API:
  • 대량 데이터 처리(batch processing) 지원.

3. Java EE의 특징

1. 표준 기반:
   • 모든 Java EE 애플리케이션은 표준화된 API를 사용하므로 다양한 애플리케이션 서버에서 동작.
2. 확장성:
   • 모듈 기반 설계를 통해 애플리케이션을 확장하기 쉽고, 대규모 애플리케이션 개발에 적합.
3. 컨테이너 관리:
   • Java EE 컨테이너가 보안, 트랜잭션, 리소스 관리, 의존성 주입 등을 자동으로 처리.
4. 플랫폼 독립성:
   • Java 기반으로 설계되었기 때문에 플랫폼에 독립적.
5. 다양한 구현체 지원:
   • 다양한 Java EE 구현체(Hibernate, WildFly, GlassFish, Apache TomEE 등)에서 실행 가능.

4. Java EE의 주요 애플리케이션 서버

Java EE 사양은 여러 애플리케이션 서버에서 구현됩니다. 대표적인 서버는 다음과 같습니다:

5. Jakarta EE와의 관계

• 2017년, Oracle이 Java EE의 관리를 Eclipse 재단에 넘기면서 이름이 Jakarta EE로 변경됨.
• 최신 표준은 Jakarta EE이며, 기존 Java EE의 발전된 버전.

6. Java EE의 주요 사용 사례

1. 엔터프라이즈 애플리케이션:
   • 대규모 비즈니스 로직을 처리하는 시스템 개발.
   • 예: 금융, 통신, 물류 시스템.
2. 웹 애플리케이션 개발:
   • JSP, Servlet, JSF 등을 사용하여 웹 애플리케이션 구현.
3. 분산 시스템:
   • EJB, JMS를 활용하여 여러 시스템 간의 통합.
4. RESTful API 개발:
   • JAX-RS를 사용하여 RESTful 웹 서비스를 개발.
5. 데이터 처리:
   • JPA와 JDBC를 통해 데이터베이스와 상호작용.

7. Java EE의 장단점

장점

1. 표준화:
   • 다양한 구현체에서 동일한 사양을 따름.
2. 풍부한 기능:
   • 엔터프라이즈 애플리케이션 개발에 필요한 대부분의 기능 포함.
3. 확장성과 유연성:
   • 대규모 시스템 설계 및 확장에 적합.
4. 컨테이너 관리:
   • 트랜잭션, 보안 등 복잡한 작업을 컨테이너가 자동 처리.

단점

1. 복잡성:
   • 학습 곡선이 높으며, 초기 설정과 구조 설계가 복잡.
2. 무거운 사양:
   • Java EE의 모든 기능을 사용하지 않더라도 큰 오버헤드가 있을 수 있음.
3. 의존성:
   • 애플리케이션 서버의 성능 및 설정에 영향을 받음.

8. Java EE의 기본 동작 흐름

1. 클라이언트 요청:
   • HTTP 요청 또는 메시지 큐를 통해 서버로 전달.
2. Web Tier 처리:
   • Servlet, JSP 또는 JSF에서 요청을 처리.
3. Business Tier 처리:
   • EJB 또는 POJO에서 비즈니스 로직 실행.
4. Database와 상호작용:
   • JPA 또는 JDBC를 통해 데이터베이스에 접근.
5. 응답 생성:
   • 처리 결과를 클라이언트로 반환.

생산성

// 저장
jpa.persist(tutor);
// 조회
Tutor tutor = jpa.find(Tutor.class, tutorId);
// 수정
tutor.setName("수정할 이름");
// 삭제
jpa.remove(tutor);

• persist란 영구히 저장한다는 뜻
• 마치 컬렉션에 저장한듯 객체가 저장되어 조회가 간편하다.
• 수정하고자 할 때 꺼낸 객체에 setName() 하면된다.

유지보수성

// 기존
public class Tutor {
		private String id;
		private String name;
}
 
// 필드 수정
public class Tutor {
		private String id;
		private String name;
		private Integer age;
}

• 객체 필드가 수정 되어도 SQL은 JPA가 알아서 처리한다.

패러다임 불일치 문제 해결

상속

연관관계

tutor.setCompany(company);
jpa.persist(company);

• Collection처럼 사용할 수 있다.

객체 그래프 탐색

Tutor tutor = jpa.find(Tutor.class, tutorId);
Company company = tutor.getCompany();

• JPA를 사용하면 신뢰할 수 있는 엔티티, 계층이 된다.
  • JOIN or SQL Query 두번 실행은 JPA로 편하게 할 수 있다.

객체 비교

Tutor tutor1 = jpa.find(Tutor.class, tutorId);
Tutor tutor2 = jpa.find(Tutor.class, tutorId);

tutor1 == tutor2; // true

• 단, 전제조건으로 동일한 트랜잭션 필수

성능

• 1차 캐시
  • SQL Query 한번만 실행

Tutor tutor1 = jpa.find(Tutor.class, tutorId); // 실행 결과 1차 캐시에 저장
Tutor tutor2 = jpa.find(Tutor.class, tutorId); // 캐시에서 조회

tutor1 == tutor2; // true

• 쓰기 지연
  • ORM과 같은 중간 기술이 있으면 한번에 모아서 요청을 보내는것이 가능하다.
  • 네트워크 통신이 한번만 발생하여 비용이 감소된다.

// 트랜잭션 시작
transaction.begin();

jpa.persist(company);
jpa.persist(tutor1);
jpa.persist(tutor2);

// 트랜잭션 제출, JDBC BATCH SQL
transaction.commit();

• 지연 로딩, 즉시 로딩
  •  

// 지연 로딩
Tutor tutor = tutorRepository.find(tutorId); // SELECT * FROM tutor
Company company = tutor.getCompany();
String companyName = company.getName(); // SELECT * FROM company

// 즉시 로딩
// SELECT t.*, c.* FROM tutor t JOIN Company c ON
Tutor tutor = tutorRepository.find(tutorId);

Company company = tutor.getCompany();
String companyName = company.getName();

• 지연로딩
  • 필요할 때만 조회하기 때문에 통신 비용 감소
• 즉시로딩
  • 한번만 조회하기 때문에 네트워크 통신 비용 감소

hibernate.dialect

📌 Hibernate가 사용하는 데이터베이스 방언(dialect)을 지정하는 설정으로 데이터베이스와 Hibernate가 상호작용할 때 특정 데이터베이스에 맞게 SQL 구문을 자동으로 조정하는 역할을 수행한다.

• 데이터베이스 방언(Dialect) = 서로 다른 데이터베이스 시스템의 SQL 문법과 기능 차이를 처리하기 위해 제공

• 방언 : SQL 표준을 지키지 않는 특정 데이터베이스 만의 고유한 기능

ex) 페이징

• MySQL : LIMIT
• Oracle : ROWNUM
• JPA는 특정 데이터베이스에 종속되지 않는다.
  • MySQL → Oracle 마음대로 변경이 가능하다.
• 실무에서 사용되는 DB의 Dialect는 대부분 이미 존재한다.

객체와 관계형 데이터베이스

📌 객체는 클래스를 통해 만들어지며 속성(field)와 기능(method)를 포함하며 관계형 데이터베이스는 데이터를 테이블 형식으로 표현하며 각 테이블은 열(column)과 행(row)으로 구성된다.

객체 지향 언어 Java

• 객체를 저장할 수 있는 다양한 종류의 Database
  1. RDB(무결성, 일관성)
  2. NoSQL
  3. File
  4. 기타 등등..
• 관계형 데이터베이스와 객체 지향의 패러다임 불일치 문제가 발생한다.

관계형 DB에 객체 저장 시 발생하는 문제점

1. 관계형 DB와 객체 간의 구조적 차이

1. 객체 지향 vs. 관계형 모델:
   • 객체지향 언어(Java, Python 등)는 객체를 중심으로 설계되며, 상태(필드)와 행동(메서드)을 결합.
   • 관계형 데이터베이스는 테이블과 행(row)을 기반으로 데이터를 저장하며, 테이블 간 관계(Primary Key, Foreign Key)를 정의.
2. 데이터 표현 차이:
   • 객체는 복잡한 데이터 구조를 포함할 수 있지만, 데이터베이스 테이블은 정규화된 단순 구조로 데이터를 저장.
3. 매핑 복잡성:
   • 객체를 RDB 테이블에 맞게 변환(매핑)하는 과정에서 많은 문제가 발생.

2. CRUD 반복 문제

객체 지향 프로그래밍에서 관계형 데이터베이스와 상호작용할 때 리소스별 CRUD 작업을 반복적으로 작성해야 하는 문제가 자주 발생합니다.

예제 상황

• 애플리케이션에 User, Product, Order라는 객체가 존재.
• 각각의 객체에 대해 CRUD(Create, Read, Update, Delete) 작업이 필요.

문제점

1. 반복적인 SQL 작성:
   • 각 리소스마다 유사한 SQL 쿼리(CRUD)를 작성해야 함.
   • 예:
     • INSERT INTO users ...
     • SELECT * FROM users ...
     • UPDATE users SET ...
     • DELETE FROM users WHERE ...
2. 코드 중복:
   • 객체를 저장하거나 읽을 때 매번 SQL을 수동으로 작성해야 하며, 이 과정에서 비슷한 코드가 반복됨.
3. 유지보수 어려움:
   • 리소스가 추가되거나 변경될 때, 관련 SQL이나 매핑 코드를 모두 수정해야 함.
4. 변경에 따른 리스크:
   • 데이터베이스 스키마가 변경되면, 관련된 모든 CRUD 코드를 수정해야 하므로 버그 발생 가능성이 증가.

INSERT, UPDATE, SELECT, DELETE

• Java Object to SQL
• SQL to Java Object

패러다임 불일치 문제

📌 객체에서는 상속과 다형성을 통해 객체 관계를 표현할 수 있지만 RDB는 이 개념을 직접 지원하지 않고 별도 매핑이 필요하다. 또한, 객체는 참조로 관계를 표현하고 RDB는 JOIN을 사용하여 관계를 결합한다.

상속

DB는 상속관계가 없다.

관계형 DB에서는 Data를 슈퍼타입, 서브타입 관계로 설정한다.

• Tutor 저장

• Tutor 조회

• 각각의 객체별로 JOIN SQL 작성, 객체 생성 및 데이터 세팅이 필요하다.
• 까다롭기 때문에 DB에 저장할 객체는 상속 관계를 사용하지 않는다.

연관관계

📌 테이블의 연관관계는 외래 키를 사용한다.

📌  객체의 연관관계는 참조를 사용한다

연관탐색

📌 객체 지향 언어에서 데이터와 동작을 함께 캡슐화하는 방식과, RDB가 데이터를 정규화된 테이블에 관계 중심으로 저장하는 방식의 차이에서 발생한다. 이로 인해 객체를 데이터베이스에 저장하거나 조회할 때 복잡한 매핑과 변환이 필요해지고 코드의 복잡성과 개발자의 부담이 증가한다.

1. 상속과 유사한 관계의 데이터베이스를 구축한 경우 상위 아키텍처는 다음 계층을 믿고 사용가능해야한다.
2. Entity가 믿고 쓸 수 있는 상속인지 확인해야한다. productRepository.findById();의 신뢰성 확인이 필요하다.
3. 매번 신뢰성 확인이 필요하니 SQL Query가 굉장히 무거워진다.
4. 진정한 의미의 계층 분할이 어렵다.
5. 필요 없는 데이터도 항상 함께 조회된다. (연관된거 싹다 들고온다)

더보기

객체의 비교

Product product1 = productRepository.findById(productId);
Product product2 = productRepository.findById(productId);

product1 == product2; // false

• 데이터는 같지만, 새로운 인스턴스기 때문에 객체의 주소값이 다르다.

결론

• 객체 지향적으로 설계하면 코드가 점점 복잡해진다.
  • SQL Query, Mapping이 까다롭다.
• Collection처럼 객체가 관리된다면 편리해진다.

// Entity 신뢰 가능
Product product = list.get(productId);
Category category = product.getCategory();

// 비교 가능
Product product1 = list.get(productId);
Product product2 = list.get(productId);

product1 == product2; // true

• JPA(Java Persistence API) 등장
  • 마치 Java의 Collection처럼 객체를 저장하고 사용할 수 있게 해준다.
  • JPA를 사용하면 패러다임 불일치 문제를 모두 해결할 수 있다.

공통 관심 사항(cross-cutting concerns)

📌 애플리케이션 전반에 걸쳐 여러 모듈이나 레이어에서 공통적으로 필요하지만, 특정 비즈니스 로직과 직접적으로 관련이 없는 기능을 의미합니다.

• 이러한 기능은 여러 곳에서 반복적으로 사용되며, 코드 중복을 초래하거나 모듈 간의 결합도를 높이는 원인이 될 수 있습니다.

• 해결방법
  • 언제나 핵심은 수정에 있다!
  1. 화면에서 로그인 하지 않으면 API를 사용하지 못하도록 막는다.
     • 유저가 HTTP 요청을 마음대로 조작할 수 있다.
  2. Controller에서 로그인 여부를 체크하는 Logic을 작성한다.
     • 실제로는 인증이 필요한 모든 컨트롤러에 공통으로 로그인 여부를 체크해야 한다.
     • 로그인 로직이 변경될 때 마다 로그인 여부를 체크하는 Logic 또한 변경될 가능성이 높다.

@RestController
@RequestMapping("/post")
public class PostController {

    @PostMapping
    public PostResponseDto create(PostCreateRequestDto request) {
        // 로그인 여부 확인 로직

        // 생성 로직
    }

    @PutMapping("/{postId}")
    public void update(
            @PathVariable Long postId,
            PostUpdateRequestDto request
    ) {
        // 로그인 여부 확인 로직
        // 수정 로직
    }

    @DeleteMapping("/{postId}")
    public void delete(@PathVariable Long postId) {
        // 로그인 여부 확인 로직
        // 삭제 로직
    }

}

• 위와같이 여러가지 로직에서 공통으로 관심이 있는 부분을 공통 관심사 라고 한다.

• 공통 관심사는 로그인뿐만 아니라 더 큰범위를 의미한다.

1. Spring AOP를 활용할 수 있다.
2. Web과 관련된 공통 관심사는 Servlet Filter나 Spring Intercepter를 사용한다.
   • HttpServletRequest 객체를 제공하기 때문에 HTTP 정보나 URL 정보에 접근하기 쉽다.
   ex) HTTP Header Cookie → 인증
3. ex ) 특정 URL의 요청은 인증을 할것이다. → URL 정보 필요

Spring AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍)

📌 로깅, 보안, 트랜잭션 관리 등과 같은 횡단 관심사를 개별적인 Aspect(관점)로 모듈화할 수 있도록 합니다.

• 이를 통해 핵심 비즈니스 로직과 부가적인 로직을 분리하여 코드의 가독성과 유지보수성을 높일 수 있습니다.
• 반복되는 공통 작업(예: 로깅, 보안, 트랜잭션 관리)을 한 곳에 모아서 관리할 수 있게 도와준다. 예를 들어 모든 메서드 실행 전에 로그를 냄기는 경우, 각 메서드에 System.out.println()을 넣는 대신, AOP로 한번만 설정하면 알아서 모든 메서드에 적용된다.

Spring AOP의 주요 개념

1. Aspect(관점)
   • 횡단 관심사를 정의한 모듈입니다. 예: 로그 기록, 트랜잭션 관리.
2. Join Point(조인 포인트)
   • 애플리케이션 실행 과정에서 Aspect를 적용할 수 있는 지점입니다. 예: 메서드 호출, 예외 발생.
3. Advice(어드바이스)
   • Join Point에서 실행되는 작업(Aspect의 구체적인 동작)입니다. Advice는 다음과 같이 구분됩니다:
     • Before: 메서드 실행 전에 실행.
     • After: 메서드 실행 후에 실행.
     • Around: 메서드 실행 전후에 실행.
     • After Returning: 메서드가 정상적으로 반환된 후 실행.
     • After Throwing: 메서드 실행 중 예외가 발생한 후 실행.
4. Pointcut(포인트컷)
   • Advice가 적용될 Join Point를 정의하는 표현식입니다.
5. Weaving(위빙)
   • Aspect를 애플리케이션의 대상 객체에 적용하는 과정입니다. Spring AOP에서는 런타임 위빙이 일반적으로 사용됩니다.

Spring AOP 특징

• Spring AOP는 프록시 기반으로 동작합니다.
• 런타임 기반 AOP를 지원하며, Java 동적 프록시나 CGLIB를 사용합니다.
• 메서드 호출 수준의 AOP를 제공합니다. (클래스 내부의 필드 변경 등에는 적용되지 않음)

Spring AOP 사용 방법

1. 의존성 추가 Spring AOP를 사용하려면 Maven 또는 Gradle에 관련 의존성을 추가합니다:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aspects</artifactId>
    <version>버전</version>
</dependency>

2. Aspect 정의 아래는 간단한 로그 Aspect 예제입니다:

@Aspect
@Component
public class LoggingAspect {
    
    @Before("execution(* com.example.service.*.*(..))")
    public void logBefore(JoinPoint joinPoint) {
        System.out.println("메서드 실행 전: " + joinPoint.getSignature().getName());
    }
    
    @After("execution(* com.example.service.*.*(..))")
    public void logAfter(JoinPoint joinPoint) {
        System.out.println("메서드 실행 후: " + joinPoint.getSignature().getName());
    }
}

3. Pointcut 표현식

• execution(* 패키지명.클래스명.메서드명(..)): 특정 메서드에 적용.
• within(패키지명..*): 특정 패키지 내 모든 클래스에 적용.
• @annotation(애너테이션): 특정 애너테이션이 적용된 메서드에만 적용.

4. AOP 활성화 AOP 기능을 활성화하려면 @EnableAspectJAutoProxy 애너테이션을 사용합니다:

@Configuration
@EnableAspectJAutoProxy
public class AppConfig {
}

Proxy

📌 대리자라는 의미로, 컴퓨터 네트워킹에서 주로 클라이언트와 서버 간의 중간에 위치하여 데이터를 중계하는 서버 또는 소프트웨어를 지칭합니다.

1. 프록시의 주요 개념

• 중간자 역할: 프록시는 클라이언트가 서버에 직접 요청을 보내지 않고, 프록시를 통해 요청과 응답이 오가게 만듭니다.
• 주소 은폐: 클라이언트의 실제 IP 주소를 감추고, 프록시 서버의 IP를 사용하여 요청을 처리합니다.
• 트래픽 제어: 요청을 필터링하거나 캐싱하는 등 트래픽을 관리합니다.

2. 프록시의 유형

1) 포워드 프록시 (Forward Proxy)

• 동작: 클라이언트가 프록시 서버를 통해 인터넷에 요청을 보냅니다.
• 사용 사례:
  • IP 숨김: 사용자의 IP 주소를 감추고 다른 주소로 대체.
  • 콘텐츠 우회: 지역 제한된 콘텐츠(예: 특정 국가에서 차단된 웹사이트) 접근.
  • 캐싱: 자주 요청되는 데이터를 저장하여 빠른 응답 제공.

2) 리버스 프록시 (Reverse Proxy)

• 동작: 서버 앞단에 위치하며, 클라이언트 요청을 받아 적절한 서버에 전달.
• 사용 사례:
  • 로드 밸런싱: 여러 서버로 트래픽을 분산하여 서버 과부하 방지.
  • 보안: 서버의 실제 위치(IP)를 숨기고 공격으로부터 보호.
  • SSL 종단: HTTPS 암호화를 처리하여 서버 부담 감소.

3) 오픈 프록시 (Open Proxy)

• 동작: 전 세계 누구나 사용할 수 있는 공개 프록시 서버.
• 특징: 익명성을 제공하지만 보안 문제가 있을 수 있음.
• 주의사항: 악의적인 활동에 이용될 가능성이 높음.

4) 투명 프록시 (Transparent Proxy)

• 동작: 사용자에게 보이지 않는 방식으로 트래픽을 중계.
• 사용 사례:
  • 네트워크 관리자에 의해 웹 필터링이나 모니터링.
  • 기업 및 공공기관에서 사용.

5) SOCKS 프록시

• 특징: TCP와 UDP 트래픽을 모두 처리 가능.
• 사용 사례:
  • P2P 파일 공유(예: 토렌트).
  • 게임에서 지연 감소 및 지역 제한 우회.

6) VPN과의 차이

• VPN은 네트워크 트래픽 전체를 암호화하는 반면, 프록시는 특정 트래픽만 처리.
• 프록시는 보안보다는 익명성과 요청 중계를 중심으로 함.

3. 프록시 사용 사례

1. 보안 및 익명성 제공
   • 사용자의 실제 IP를 숨기고, 온라인 활동을 익명으로 수행.
2. 콘텐츠 필터링 및 접근 제한
   • 기업이나 학교에서 불법적이거나 부적절한 콘텐츠 접근 차단.
3. 지역 제한 콘텐츠 우회
   • 예: 특정 국가에서 차단된 Netflix 콘텐츠를 시청.
4. 트래픽 최적화
   • 캐싱을 통해 대역폭을 줄이고, 요청 속도를 높임.
5. 분산 처리
   • 리버스 프록시를 사용하여 대규모 트래픽을 여러 서버로 나누어 처리.
6. 데이터 로깅 및 모니터링
   • 네트워크 트래픽 분석 및 기록.
7. 테스트 및 디버깅
   • 웹 개발에서 네트워크 요청과 응답을 확인하거나 조작.

4. 프록시 사용 시 고려사항

1. 성능:
   • 추가적인 네트워크 홉으로 인해 지연이 발생할 수 있음.
2. 보안:
   • 신뢰할 수 없는 프록시 서버 사용 시 개인 정보가 유출될 위험.
3. 법적 문제:
   • 지역 제한 콘텐츠 우회 등은 해당 국가의 법률을 위반할 수 있음.
4. 설정 복잡성:
   • 특정 애플리케이션이나 네트워크 환경에서는 복잡한 설정이 필요할 수 있음.

아래는 **프록시(Proxy)**와 유사 기술(VPN, NAT, 방화벽 등)을 비교한 표입니다. 각 기술의 특징, 주 용도, 장단점을 기준으로 작성했습니다.