인증관리자(Authentication Manager), 접근 결정 관리자(Access Decision Manager)를 통해 사용자의 리소스 접근을 제어
인증 관리자 ⇒ UsernamePasswordAuthenticationFilter
접근 결정 관리자 ⇒ FilterSecurityInterceptor
보안과 관련하여 체계적으로 많은 옵션을 제공하여 편리하게 사용할 수 있다.
Filter 기반으로 동작하여 MVC와 분리하여 동작한다.
어노테이션을 통한 간단한 설정
기본적으로 Session & Coockie 방식으로 인증한다.
⚠️Spring Security 5.7.x 버전에 대한 이슈 사항
public class SecurityConfig extends WebSecurityConfigurerAdapter{}
5.6.x 버전 이하에서는 WebSecurityConfig 클래스에서 WebSecurityConfiguredAdapter를 상속받아서 사용했다
5.7.x 버전부터는 Deprecated되어서 사용이 안됨!
5.7.x 버전 이상부터는 컴포넌트 기반의 Configuration을 구성하는 것으로 권장된다.
Spring Security Authentication Architecture
(1) 전체적인 Spring Security 흐름도와 (2) 아이디와 암호를 입력했을 때 이를 처리하는 필터는 AuthenticationFilter이다. 해당 필터는 다음 그림과 같은 순서로 동작한다.
사용자가 로그인 정보와 함께 인증 요청을 한다 → Http Request (사용자가 Form을 통해 로그인 정보를 입력하고 인증 요청을 보낸다.)
AuthenticationFilter(사용할 구현체 UsernamePasswordAuthenticationFilter)가 HttpServletRequest에서 사용자가 보낸 아이디와 패스워드를 인터셉트(가로챈다, 확인)한다. 가로챈 정보를 통해 UsernamePasswordAuthenticationToken의 인증용 객체를 생성한다.
HttpServletRequest에서 꺼내온 사용자 아이디와 패스워드를 진짜 인증을 담당할 AuthenticationManager인터페이스(구현체 - ProviderManager)에게 인증용 객체(UsernamePasswordAuthenticationToken) 객체를 전달한다.
클라이언트(유저)에게 session ID(JSESSION ID)와 함께 응답을 한다. 이후 요청에서는 요청 쿠키에서 JSESSION ID정보를 통해 이미 로그인 정보가 저장되어 있는지 확인하고 이미 저장되어 있고 유효하면 인증처리를 한다.
성공시 AuthenticationSuccessHandle를 실행한다.
실패시 AuthenticationFailureHandler를 실행한다.
사용자 정보를 저장한다는건 Session-Cookie 방식을 사용한다는걸 의미한다.
1. AuthenticationManager - 인증 담당
AuthenticationManager - 인증 담당 관리
유저의 요청을 AuthenticationFilter에서 Authentication 객체로 변환해 AuthenticationManager(ProviderManager)에게 넘겨주고, AuthenticationProvider(DaoAuthenticationProvider)가 실제 인증을 한 이후에 인증이 완료되면 Authentication객체를 반환해준다.
AbstractAuthenticationProcessingFilter: 웹 기반 인증요청에서 사용되는 컴포넌트로 POST 폼 데이터를 포함하는 요청을 처리한다. 사용자 비밀번호를 다른 필터로 전달하기 위해서 Authentication 객체를 생성하고 일부 프로퍼티를 설정한다.
AuthenticationManager: 인증요청을 받고 Authentication을 채워준다.
AuthenticationProvider: 실제 인증이 일어나고 만약 인증 성공시 Authentication 객체의 authenticated = true로 설정해준다.
Spring Security 는 ProviderManager라는 AuthenticationManager인터페이스의 유일한 구현체를 제공한다. ProviderManager 는 하나 또는 여러 개의 AuthenticationProvider 구현체를 사용할 수 있다. AuthenticationProvider는 많이 사용되고 ProviderManager(AuthenticationManager 의 구현체) 와도 잘 통합되기 때문에 기본적으로 어떻게 동작하는 지 이해하는 것이 중요하다.
2. Security Context Holder
Spring Security는 인증이 완료되면 아이디, 패스워드를 가진 사용자의 principal 과 credential 정보를 Authentication에 담는다.
그 Authentication 정보를 Security Context에 보관한다.
그리고 그 Security Context를 Security Context Holder에 담아 보관한다.
User.withUsername, password, roles 메서드를 사용하여 사용자 정보를 설정한다.
passwordEncoder().encode("1234")를 사용하여 비밀번호를 암호화한다.
테스트나 데모용으로 메모리에 사용자 정보를 저장하는 방식이다. 프로젝트 초기에 하면 좋을듯
2. 데이터베이스를 사용한 사용자 인증 방법 - 2
@Service
@RequiredArgsConstructor
public class CustomUserDetailsService implements UserDetailsService {
private final UserRepository userRepository;
@Override
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
User user = userRepository.findByUsername(username); // 데이터베이스에서 사용자 이름을 기준으로 사용자를 조회
if(user == null){
throw new UsernameNotFoundException("사용자가 없습니다.");
}
// UserBuilder를 사용하여 UserDetails 객체를 생성
// withUsername(username)를 호출하여 사용자 이름을 설정
UserBuilder userBuilder = org.springframework.security.core.userdetails.User.withUsername(username);
userBuilder.password(user.getPassword()); // 암호화된 비밀번호를 설정
userBuilder.roles(user.getRoles().stream().map(role -> role.getName()).toArray(String[]::new));
return userBuilder.build(); // 완성된 UserDetails 객체를 반환
}
}
저장소 : 데이터베이스에서 사용자의 정보를 조회한다.
사용자 정보의 변경, 추가, 삭제가 데이터베이스에서 이루어진다.
사용자가 직접 만든 UserRepository를 사용하여 사용자 정보(데이터)를 가져온다.
UserBuilder를 사용하여 UserDetails 객체를 생성합니다.
두 번재 방식을 풀이 하자면,
UserDetailsService 인터페이스는 기본적으로 사용자 이름을 통해 사용자를 로드하는 기능을 제공한다.
UserDetailsService 의 메서드 중 loadUserByUsername 메서드는 데이터베이스에서 주어진 사용자 이름(username)을 기반으로 사용자의 세부 정보를 검색하고 반환하는 역할을 하는 메서드이다.
웹 어플리케이션 실행 -> 엔티티 매니저 팩토리 생성 -> 요청들에 따라 각각 엔티티 매니저 팩토리에서 엔티티 매니저를 생성 -> 각각의 매니저가 db 커넥션을 이용해 처리.
1.3 영속성 컨텍스트
영속성 컨텍스트는 JPA를 이해하는데 가장 핵심이다.
“엔티티를 영구 저장하는 환경"이라는 의미
**EntityManager.persist("Entiy")**
persist 메서드를 호출하는 것은 객체를 db에 저장한다고 생각할 수 있지만 사실은 "엔티티를 영속화" 하는 것으로, db에 직접 저장하는 것이 아니라, "영속성 컨텍스트"에 저장하는 것이다.
객체를 db에 저장하는구나? -> “엔티티를 영속화한다” -> 사실은 db에 저장하는게 아니라, 영속성 컨텍스트에 저장하는 거임.
영속성 컨텍스트는 논리적인 개념. 눈에 보이지 않음. 엔티티 매니저를 통해서 영속성 컨텍스트에 접근.
엔티티 매니저를 생성하면, 영속성 컨텍스트라는 공간이 생긴다고 생각하면 된다. (대충 1차 캐시를 영속성 컨텍스트라고 생각해도 될 것 같다. 물론 어느정도 차이가 있다).
1.3.1 엔티티 매니저와 영속성 컨텍스트의 상호작용 코드
import jakarta.persistence.EntityManager;
import jakarta.persistence.EntityManagerFactory;
import jakarta.persistence.Persistence;
public class Example {
public static void main(String[] args) {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("ExamplePU");
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
// 새 엔티티 생성 및 영속화
User newUser = new User("carami", "carami@example.com");
em.persist(newUser);
// 엔티티 조회 ->
// 위 newUser가 영속화되었기 때문에 영속성 컨텍스트에 있는 newUser를 리턴
User user = em.find(User.class, newUser.getId());
em.getTransaction().commit();
em.close();
}
}
1.4 영속성 컨텍스트의 이점
1차 캐시
약간 중간에 있는 느낌. 버퍼링도 가능하고, 캐싱도 가능함.
사실상 1차 캐시가 영속성 컨텍스트. 스프링에서는 조금 달라지긴 하지만 일단은….
.Persist() 하면 1차 캐시에 pk-엔티티 이렇게 저장
조회를 하면, db를 바로 뒤지는게 아니라 1차캐시에서 조회함
만약 1차 캐시에 없으면, db에서 조회하고, 이 값을 1차캐시에 다시 저장하고, 이걸 반환.
어플리케이션에서 공유하는 캐시는 2차 캐시라고 함.
디비에서 한번 가져오고, 계속해서 영속성 컨텍스트에다가 저장.
성능적인 이점 보다는 컨셉이 주는 이점. 객체지향적인 느낌.
1.5 영속 엔티티의 동일성 보장.
”== “ 비교하면 어떻게 되니? 같은 객체로 취급됨. 마치 자바 컬렉션에서 꺼낸 것 처럼. 1차 캐시가 있기 때문에 가능.
1차 캐시로 “반복 가능한 읽기(repeatable read) 등급의 트랜잭션 격리 수준을 데이터베이스가 아닌 어플리케이션 차원에서 제공한다.
2. 엔티티의 생명주기
2.1 엔티티의 생명주기
비영속 (new,transient)
위와 같이 최초로 객체를 생성한 상태, 영속성 컨텍스트와는 아무런 관련 없는 상태
**Member member = new Member();**
영속(managed)
영속성 컨텍스트에 의해 관리되는 상태
물론 위와 같이 persist 메서드를 호출한다고 해서 쿼리가 바로 날아가지는 않고, tx.commit() 시점에 실질적인 쿼리가 날아간다.
즉, 이 시점에 바로 DB에 반영되는 것은 아니다.
em.persist(member);
분리된(Detached) 상태: 엔티티가 영속성 컨텍스트에서 분리된 상태
삭제된(Removed) 상태: 엔티티가 삭제되어 데이터베이스에서도 삭제될 상태
2.1.1 비영속 (new,transient)
멤버객체를 생성을 하고, 엔티티 매니저에 안 넣은 상태
Member member = new Member();
member.setId(“memberID”)
-> JPA와 아예 관계가 없음
2.1.2 영속 (managed)
em.persist(member)를 통해서, 영속성 컨텍스트라는 곳에 들어가 있는 상태.
멤버가 이제 관리가 된다라는 의미.
사실 이 때 db에 저장되는게 아님.
persist()메서드를 쓸 때 쿼리가 날아가는게 아님.
*tx.commit()을 하는 때에 쿼리가 날아가게 됨.
2.1.3 영속 -> 준영속
준영속 상태
만약, FIND를 했는데 영속성 컨텍스트에 없으면 DB에서 가져와서 1차 캐시에 올려놓음.
즉, 영속 상태가 됨.
근데 만약에 이거 영속성 컨텍스트에서 관리하고 싶지가 않아, 하면 detach()를 씀.
Em.detach() 특정 컨텍스트만 준영속으로 만들 떄.
Em.clear() em이라는 영속성 컨텍스트 안에 있는 걸 전부 날려버림. 즉 쿼리가 안날라감.
Em.close() 하면 em을 닫아버림. Jpa가 관리가 안되겠지?
2.2 생명주기 전환 메서드
persist(entity): 엔티티를 영속 상태로 만든다.
merge(entity): 분리된 상태의 엔티티를 다시 영속 상태로 복구한다.
remove(entity): 엔티티를 삭제 상태로 전환한다.
detach(entity): 엔티티를 분리 상태로 만들며, 이를 통해 성능 및 메모리 사용 최적화, 트랜잭션 관리, 테스트와 디버깅 등을 수행할 수 있다.
2.3 엔티티 클래스의 조건
@Entity 어노테이션: 클래스는 @Entity 어노테이션으로 표시하여, 해당 클래스가 JPA 엔티티임을 나타낸다.
식별자: 각 엔티티는 유일하게 식별될 수 있는 식별자를 @Id 어노테이션을 사용하여 지정한다.
기본 생성자: 엔티티 클래스는 JPA 구현체가 엔티티 인스턴스를 프로그래밍적으로 생성할 수 있도록 public 또는 protected의 기본 생성자를 가져야 한다.
클래스 수준에서의 제한: 최종 클래스(final class)가 아니어야 하며, 변경 가능해야 하고, 일반 Java 객체처럼 메서드나 속성을 추가할 수 있다.
2.3.1 엔티티 예제 코드
package com.example.jpa;
import jakarta.persistence.*;
@Entity // 클래스는 @Entity 어노테이션으로 표시 해당 클래스가 JPA 엔티티 명시
@Table(name = "user")
public class User {
@Id // 각 엔티티는 유일하게 식별될 수 있는 식별자
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(name = "username")
private String username;
@Column(name = "email")
private String email;
// 기본 생성자
public User() { }
// 추가적인 생성자와 setter, getter가 올 수 있다.
}
3. 지연 실행
3.1 지연 실행
배칭: JPA는 여러 SQL 문을 함께 배치 처리할 수 있어 데이터베이스로의 왕복 횟수 를 줄일 수 있다.
순서 보장: SQL 작업이 올바른 순서로 실행되도록 보장하여 참조 무결성을 유지한다.
3.1.1 변경 축적
최적화: JPA는 실행해야 할 SQL 문의 수를 최적화할 수 있습니다. 예를 들어, 한 트랜 잭션 내에서 엔티티가 여러 번 수정된 경우, JPA는 최종 상태에 대해서만 하나의 UPDATE 문을 발행할 필요가 있습니다.
불필요한 작업 감소: 데이터베이스에 불필요한 쓰기 작업을 방지합니다.
3.1.2 트랜잭션 무결성 보장
원자성: 트랜잭션 경계 내에서 발생하는 모든 변경 사항은 완전히 커밋되거나 오류가 발생할 경우 전체적으로 롤백된다.
격리성: 트랜잭션이 커밋될 때까지 변경사항이 다른 트랜잭션에 보이지 않는다.
3.1.3 자원 사용 최적화
잠금 감소: 쓰기 작업을 지연함으로써 데이터베이스 행에 대한 잠금 시간을 줄일 수 있으며, 이는 잠금 경합을 줄이고 애플리케이션의 동시성을 개선해준다.
연결 사용 효율성: 데이터베이스 연결이 실제 필요한 SQL 실행에만 사용되므로, 연결 사용이 더 효율적이다.
예시 코드 - 트랜잭션 관리
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
// 엔티티가 저장되지만 데이터베이스에는 즉시 기록되지 않습니다.
User newUser = new User("carami", "carami@example.com"); em.persist(newUser);
// 추가 수정 사항이 있을 수 있음
newUser.setEmail("carami@example.com");
// 커밋: 모든 변경사항이 데이터베이스에 효율적으로 반영됩니다.
em.getTransaction().commit();
em.close();
예시 코드 - 조회시 변경사항에 따라 자동 업데이트
import jakarta.persistence.EntityManager;
import jakarta.persistence.EntityManagerFactory;
import jakarta.persistence.Persistence;
public class UpdateExample {
public static void main(String[] args) {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("ExamplePU");
EntityManager em = emf.createEntityManager();
try {
em.getTransaction().begin();
// ID로 특정 엔티티를 조회
User user = em.find(User.class, 1L);
// 엔티티의 필드 값을 변경
if (user != null) {
user.setEmail("updated.email@example.com"); // 이메일 필드 수정
}
// 트랜잭션을 커밋할 때 변경된 내용이 자동으로 데이터베이스에 반영
em.getTransaction().commit();
} finally {
em.close();
emf.close();
}
}
}
4. 영속성 유닛(Persistence Unit)
4.1 영속성 유닛
엔티티 클래스와 데이터베이스 연결 설정을 그룹화하는 JPA의 구성 단위
애플리케이션에서 데이터를 관리하는 방법을 정의하고, 주로 persistence.xml 파일 내에 설정된다.
4.2 영속성 유닛의 주요 구성 요소
엔티티 클래스 목록: 영속성 유닛은 하나 이상의 엔티티 클래스를 포함할 수 있으며, 이들은 데이터베이스 테이블과 매핑된다.
데이터 소스 설정: 데이터베이스 연결을 위한 설정 정보를 포함하며, 이는 JPA 구현체가 데이터베이스와의 연결을 관리하는 데 사용된다.
트랜잭션 타입: JPA는 리소스 로컬(Resource-local)과 JTA(Java Transaction API) 트랜잭션 두 가지 타입을 지원하며, 사용 환경에 따라 적합한 트랜잭션 관리 방식을 선택할 수 있다.
5. 엔티티 매핑
앞서.. jpa에서 제일 중요하게 볼 것
메커니즘
매핑 ⇒ 객체와 테이블 매핑
5.1 엔티티 매핑 소개
객체와 테이블 매핑 : @Entity, @Table
피륻와 컬럼 매핑 : @Column
기본 키 메핑 : @Id
연관관계 매핑 : @ManyToOne, @JoinColumn
5.1.1 기본 엔티티 매핑
@Entity
@Entity 어노테이션은 클래스가 JPA 엔티티임을 나타내며,
이 클래스의 인스턴스는 데이터베이스에 저장될 데이터를 나타낸다.
주요 속성
name: 엔티티 이름 지정 —> 그냥 기본 값 쓰는게 정신건강에 좋음
catalog: 엔티티가 속할 데이터베이스 카탈로그 지정
schema: 엔티티가 속할 데이터베이스 스키마 지정
table: 엔티티에 매핑될 데이터베이스 테이블 이름 지정
readOnly: 엔티티의 읽기 전용 여부 설정
inheritance: 엔티티의 상속 전략 지정
@Id
@Id 어노테이션은 클래스의 필드를 테이블의 기본 키(primary key)로 지정하며,
각 엔티티 인스턴스를 유일하게 식별하는 데 사용된다.
@GeneratedValue(…)
@GeneratedValue 어노테이션은 기본 키의 값을 자동으로 생성할 방법을 명시
주요 기본 키 생성 전략
GenerationType.AUTO
JPA 구현체가 자동으로 가장 적합한 전략을 선택
GenerationType.IDENTITY
데이터베이스의 ID 자동 생성 기능을 사용하여 기본 키를 생성한다.
기본 키 생성을 데이터베이스에 위임.
(MYSQL의 경우 AUTO-INCREMENT가 이 경우) “나는 모르겠고 디비야 니가 알아서 해조..”
GenerationType.SEQUENCE
데이터베이스의 시퀀스를 사용하여 기본 키를 생성한다.
필드의 데이터 타입을 Long으로 하는 것을 추천.
GenerationType.TABLE
키 생성을 위한 별도의 데이터베이스 테이블을 사용한다.
@Table
@Table 어노테이션은 엔티티 클래스가 데이터베이스의 어떤 테이블에 매핑될 것인지를 명시한다.
@Table(name=”MBR”) 로 하면 DB의 “MBR”테이블로 쿼리가 나감.
주요 속성
name: 매핑될 테이블의 이름을 지정하며, 지정하지 않으면 클래스 이름을 사용한다.
catalog: 엔티티가 속할 데이터베이스 카탈로그를 지정한다.
schema: 엔티티가 속할 데이터베이스 스키마를 지정한다.
uniqueConstraints: 테이블 수준에서 유니크 제약 조건을 지정하며, 여러 열을 포함할 수 있는 제약 조건을 정의할 때 사용된다.
@Column
@Column 어노테이션은 엔티티의 필드가 데이터베이스 테이블의 어떤 열에 매핑될 것인지를 정의한다.
주요 속성
name: 필드가 매핑될 테이블의 열 이름을 지정하며, 지정하지 않으면 필드 이름이 사용
nullable: 열이 널(Null) 값을 허용할지 여부를 지정하며, 기본값은 true
length: 문자열 필드의 경우 열의 최대 길이를 지정하며, 기본값은 255
unique: 이 열이 테이블 내에서 유니크한 값을 가져야 할지 지정 —> 잘 안씀
insertable 및 updatable: 이 필드가 데이터베이스에 삽입하거나 업데이트할 수 있는지 여부를 지정하며, 둘 다 기본값은 true이다.
Precision, scale : bigint나 소수점 쓸 때 쓰면 됨
5.1.2 관계 매핑 (@OneToMany, @ManyToOne)
@OneToMany와 @ManyToOne 관계는 엔티티 간의 일대다 관계를 매핑할 때 사용하는 어노테이션이다.
@OneToMany 관계
한 엔티티가 다른 엔티티 여러 개와 관계를 가질 수 있다.
@ManyToOne 관계
엔티티 여러 개가 다른 엔티티 하나와 관계를 가질 수 있다.
5.2 엔티티 등록
영속성 컨텍스트 안에는 1차캐시 말고도, “쓰기 지연 sql 저장소”가 있음
.persist()하면, jpa가 엔티티를 분석을 해서 “쓰기 지연 sql 저장소”에다가 쿼리문을 보관해 놓음. 차곡 차곡 여기다가 쿼리문을 저장해 놓음
이 쿼리가 언제 날라가냐? Transaction.commit()할 때 날라가는 거임. 플러쉬라고 함. 이 때 실제 db에 커밋됨
entity 객체는 기본 생성자가 있어야 함
이렇게 하면 버퍼링이라는게 가능. 하이버네이트 같은 경우에는 옵션이 있음<”hibernate.jdbc.batch_size, value = " ... "> 이 속성
쿼리를 모았다가 디비에 한방에 보내는 것 —> 실전에서는 딱히 크게 얻을 이점이 많지는 않지만, 이러한 최적화의 여지가 생김.
5.3 엔티티 수정 : 변경감지(더티 체킹)
jpa의 목적은 마치 자바 컬렉션에 넣은 것처럼 다루는 거임
만약에 컬렉션 값을 수정 할 때 그 값을 꺼내서 수정하고 다시 그걸 저장함? 안함. 딱 찾아온 다음에 변경만 함
em.find() 해서 가져온 값을 member.set() 해서 수정 하고, 다시 em.persist 하면 안됨!!!!xxxx —> 마치 자바 컬렉션에서 값 바꾸듯이 바꼈는데 sql이 날라감
commit()을 하면, flush()가 호출됨. 무슨 일이 벌어지냐, 엔티티와 스냅샷을 비교함
db에서 가져오든 해서 최초로 영속성 컨텍스트에 들어온 상태를 “스냅샷”을 띄워 둠
만약 memberA를 변경하고 flush를 하면, 그 순간 엔티티와 스냅샷을 쫙 비교를 함
비교를 해보고 어 memberA가 바꼈네? 하면 쓰기 지연 SQL 저장소에다가 UPDATE 쿼리를 저장해 두고, 이걸 DB에 날려줌
즉, em.find() → em.set() → em.getTransaction.commit() 으로 진행
5.4 엔티티 삭제
Em.remove() 하면 delete() 쿼리 생성. 커밋 시점에 날라감
결론 : jpa는 값을 바꾸면 트랜잭션 커밋 시점에 알아서 업데이트 쿼리가 날아가는 구나. 라고 생각하고, 따로 persist()를 안하는게 정답임
5. 5 생명주기 변환 메서드 사용 관련 예
테이블 생성
CREATE TABLE schools (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255) NOT NULL
);
CREATE TABLE students (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255) NOT NULL,
school_id BIGINT,
FOREIGN KEY (school_id) REFERENCES schools(id)
);
-- 테이블 INSERT문
-- Schools 추가
INSERT INTO schools (name) VALUES ('Greenwood High School');
INSERT INTO schools (name) VALUES ('Riverside Academy');
-- Students 추가
INSERT INTO students (name, school_id) VALUES ('Alice', 1);
INSERT INTO students (name, school_id) VALUES ('Bob', 1);
INSERT INTO students (name, school_id) VALUES ('Charlie', 1);
INSERT INTO students (name, school_id) VALUES ('David', 2);
INSERT INTO students (name, school_id) VALUES ('Eva', 2);
Entity 클래스 - School
package com.example.jpa;
import jakarta.persistence.*;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
import java.util.ArrayList;
import java.util.List;
@Entity
@Table(name="schools")
@Getter@Setter
@NoArgsConstructor
public class School {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(nullable = false)
private String name;
// cascade: 학교가 수정되거나 삭제되면 연관되어있던 학생도 같이 수정되거나 삭제
// orphanRemoval: 부모(학교) 엔티티와 연관관계가 끊어진 자식(학생) 엔티티를 삭제
@OneToMany(mappedBy = "school", cascade = CascadeType.ALL, orphanRemoval = true) // 학교 1 : 학생 n
private List<Student> students = new ArrayList<>(); // 일대다 관계
public School(String name) {
this.name = name;
}
}
Entity 클래스 - Student
package com.example.jpa;
import jakarta.persistence.*;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
@Entity
@Table(name="students")
@Getter@Setter
@NoArgsConstructor
public class Student {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(nullable = false)
private String name;
@ManyToOne // 본인 기준 관계(학생 n : 학교 1)
@JoinColumn(name = "school_id") // 조인 컬럼명
private School school; // school_id를 사용하기 위한 방법
public Student(String name, School school) {
this.name = name;
this.school = school;
}
}
조회, 삽입, 수정, 삭제 예제
package com.example.jpa;
import jakarta.persistence.*;
import lombok.extern.slf4j.Slf4j;
@Slf4j
public class SchoolExamMain {
private static void find(){
EntityManager em = JPAUtil.getEntityManagerFactory().createEntityManager();
em.getTransaction().begin();
try{
// 1번 학교 인스턴스 생성 후 이름 출력
School school = em.find(School.class, 1L);
log.info("schhol name : {}", school.getName());
// 1번 학교의 학생들 이름 출력
for (Student student : school.getStudents()) {
log.info("student name : {}", student.getName());
}
// 5번 학생의 이름과 학교이름 출력
Student student = em.find(Student.class, 5L);
log.info("student name: {}", student.getName());
log.info("school name: {}", student.getSchool().getName());
em.getTransaction().commit();
} finally {
em.close();
}
}
private static void create(){
EntityManager em = JPAUtil.getEntityManagerFactory().createEntityManager();
em.getTransaction().begin();
try{
School school = new School("LionSchool");
Student student1 = new Student("홍길동", school);
Student student2 = new Student("아무개", school);
Student student3 = new Student("삽살개", school);
school.getStudents().add(student1);
school.getStudents().add(student2);
school.getStudents().add(student3);
// 영속화
em.persist(school);
// 실제 db와 비교해 반영
em.getTransaction().commit();
}finally {
em.close();
}
}
private static void update(){
EntityManager em = JPAUtil.getEntityManagerFactory().createEntityManager();
em.getTransaction().begin();
try{
// find: 이미 영속성 컨텍스트에 존재
School school = em.find(School.class, 2L);
school.setName("update School Name");
em.getTransaction().commit();
}finally {
em.close();
}
}
private static void delete(){
EntityManager em = JPAUtil.getEntityManagerFactory().createEntityManager();
em.getTransaction().begin();
try{
School school = em.find(School.class, 5L);
// cascade 속성->학교가 삭제될 때 해당 학교에 소속되어 있는 학생들도 삭제
em.remove(school);
em.getTransaction().commit();
}finally {
em.close();
}
}
public static void main(String[] args) {
// find();
// create();
// update();
delete();
}
}
6. 플러시
6.1 플러시
영속성 컨텍스트의 변경내용을 데이터베이스에 반영.
보통 db 트랜잭션이 커밋 될 때 플러시가 일어남.
쌓아놓은 sql문이 날라가는 것. 영속성 컨텍스트의 쿼리들을 db에 쭉 날려주는 것.
6.1.1 플러시 발생
.commit() 되면 자동으로 발생.
변경 감지(더티 체킹), 수정된 엔티티를 쓰기 지연 sql 저장소에 등록함.
쓰기 지연 sql 저장소의 쿼리를 db에 전송 (등록,수정,삭제 쿼리)를 쫙 보내는거임.
플러시가 발생한다고 해서 커밋 이 발생하는건 아니고…
6.2 영속성 컨텍스트를 플러시 하는 방법
em.flush()
직접 호출 —> 진짜로 이렇게 쓰는 경우는 없음
트랜잭션 커밋
플러시 자동 호출
Jpql 쿼리 실행
플러시 자동 호출
Q. 플러시를 하면 1차 캐시가 지워지나요?
아니요. 오직 쓰기 지연 sql 저장소에 있는 쿼리들만 db로 날려버리는 거임. 뭔가 바뀐거 이런것만 데이터베이스에 반영이 되는 것.
Q. jpql에서 플러시가 자동으로 호출되는 경우?
만약 persist만 한 상태에서 중간에 jpql로 조회하는 쿼리를 날린다면, 아무것도 안날라올 수도 있음. 따라서, jpql은 무조건 플러시를 한번 날리고 시작함. 아 그래서 날라가는 구나 라고 생각하면 됨.
Q. 플러시 모드 옵션?
딱히 쓸 일은 없음.
FlushModeType.COMMIT – 커밋 할 때만 플러시, 쿼리에는 플러시를 안한다. 위 같은 경우에 만약 JPQL을 하는데 뭐 아예 다른 테이블을 가져오고 그런 경우에는 굳이 플러시를 할 필요가 없겠지? 근데 굳이 플러시를 하고 싶지 않을 수도 있음. 정 원하면 플러시 모드를 커밋으로 바꾸라 -> 큰 도움이 되지는 않습니다. 걍 AUTO로 쓰세요. 손대지 말고.
Statement: 하나 이상의 문으로 구성되며, 각각의 문은 효과, 작업, 리소스 및 조건을 정의
Effect: 이 문서의 효과를 Allow 또는 Deny로 명시
Action: 허용하거나 거부할 작업을 정의
Resource: 작업이 적용될 리소스를 명시
Condition: 특정 조건 하에서만 문을 적용하는 선택적 요소
2. AWS CLI(AWS Command Line Interface)
AWS CLI는 AWS 서비스를 관리하기 위해 명령줄 인터페이스를 제공하는 도구이며,
AWS CLI를 사용하면 스크립트를 작성하여 AWS 리소스를 자동으로 관리하고, AWS 서비스와 상호 작용할 수 있다.
이를 통해 AWS Management Console에서 제공하는 모든 기능을 명령줄에서 수행할 수 있다.
2.1 AWS CLI 명령어 구조
aws <service> <command> [subcommand] [parameters]
aws : AWS CLI를 실행하는 기본 명령어입니다.
<service> : AWS 서비스의 이름을 지정
<command> : 수행할 작업을 지정
[subcommand] : 일부 명령어는 추가 하위 명령어를 가짐
[parameters] : 명령어에 전달할 추가 매개변수
2.2 명령어 예제
2.2.1 AWS CLI 도움말 사용법
aws help # 기본 도움말
aws <service> help # 특정 서비스 도움말
aws s3 help # s3 서비스 도움말
aws <service> <command> help # 특정 명령어 도움말
aws s3 ls help # s3 버킷을 나열하는 명령어에 대한 도움말
2.2.2 주요 AWS 서비스에 대한 기본 명령어 - s3
오류가 발생한다면 적절한 권한을 추가해줘야한다.
aws s3 ls # s3 버킷 나열
aws s3 mb s3://my-new-bucket # 새 s3 버킷 생성
aws s3 cp myfile.txt s3://my-new-bucket/ # s3 버킷에 파일 업로드
aws s3 cp s3://my-new-bucket/myfile.txt . # s3 버킷에서 파일 다운로드
aws s3 rb s3://my-new-bucket --force # s3 버킷 삭제
# IAM 사용자 나열
aws iam list-users
# 새 IAM 사용자 생성
aws iam create-user --user-name carami-user
# IAM 사용자에 정책 첨부
aws iam attach-user-policy --user-name carami-user --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess
# IAM 사용자 삭제
aws iam delete-user --user-name newuser
2.2.5 AWS IAM 사용자 삭제 가이드
AWS IAM 사용자를 삭제할 때, 해당 사용자에게 연결된 모든 정책을 먼저 분리해야 한다.
사용자가 그룹에 속해 있거나, 인라인 정책이나 관리형 정책이 연결되어 있을 경우 이를 모두 제거해야 한다.
◾ 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라고 하였다. 하지만 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다.
◾ 결국 고정할인 정책에서 정률할인 정책으로 변경을 요구하였다...!
1. 요구사항 및 설계
◾ DiscountPolicy 인터페이스가 있으니 그냥 FixDisCountPolicy -> RateDiscountPolicy만 추가로 개발하여 변경한다.
// 할인 정책 역할
public interface DiscountPolicy {
/**
* 할인 대상 금액
*/
int discount(Member member, int price);
}
2.RateDiscountPolicy추가 및 테스트
RateDiscountPolicy
// 새로운 할인 정책
@Component // 각 클래스가 컴포넌트 스캔의 대상이 되도록 에노테이션을 붙여줌
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {
private int discountPercent= 10;
@Override
public int discount(Member member, int price) {
if (member.getGrade() == Grade.VIP) {
return price * discountPercent / 100;
}else {
return 0;
}
}
}
Ctrl + Shift + T 를 누르면 테스트 파일을 생성해준다.
RateDiscountPolicyTest
class RateDiscountPolicyTest {
RateDiscountPolicy discountPolicy = new RateDiscountPolicy();
// 할인 대상일 경우 실행될 테스트
@Test
@DisplayName("VIP는 10% 할인이 적용되어야 한다")
void vip_0() {
//given
Member member = new Member(1L, "memberVIP", Grade.VIP);
//when
int discount = discountPolicy.discount(member, 10000);
//then
assertThat(discount).isEqualTo(1000);
}
// 할인 대상이 아닐 경우 실행될 테스트
@Test
@DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다")
void vip_x() {
//given
Member member = new Member(2L, "memberBASIC", Grade.BASIC);
//when
int discount = discountPolicy.discount(member, 10000);
//then
assertThat(discount).isEqualTo(0);
}
}
◾@DisplayName 은 JUnit5 부터 지원하는 기능으로 테스트 메서드의 이름을 지정해 줄 수 있다.
◾Assertions는 static import 하는게 좋음 (Alt + Enter 누르고 두번째꺼 선택)
3. 방금 추가한 새로운 할인 정책의 문제점은 무엇일까? --> 새로운 할인 정책 적용해보자
OrderServiceImpl
// orderService 구현체 Impl
@Component // 각 클래스가 컴포넌트 스캔의 대상이 되도록 에노테이션을 붙여줌
@RequiredArgsConstructor // => final이 붙은 필드에 대한 생성자를 자동 만들어 준다. >>> lombok 설치 필수 = @Autowired 사용할 필요xx
public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository; //인터페이스에만 의존
private final DiscountPolicy discountPolicy; // 인터페이스에만 의존
// private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); // 구현체에 의존, DIP 위반
// private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
// 생성자(OrderServiceImpl) 에서 여러 의존관계도 한번에 주입 가능
// @MainDiscountPolicy 생성자 자동 주입
// @Autowired
// public OrderServiceImpl(MemberRepository memberRepository, @MainDiscountPolicy DiscountPolicy discountPolicy) {
// this.memberRepository = memberRepository;
// this.discountPolicy = discountPolicy;
// }
/**
* 주문 생성
*/
@Override
public Order createOrder(Long memberId, String itemName, int itemPrice) {
Member member = memberRepository.findById(memberId);
int discountPrice = discountPolicy.discount(member, itemPrice);
return new Order(memberId, itemName, itemPrice, discountPrice);
}
//테스트 용도
// public MemberRepository getMemberRepository() {return memberRepository;}
}
◾원래 있던 discountPolicy를 FixDiscountPolicy -> RateDiscountPolicy로 변경하면 된다.
◾But, 이렇게 하면 OCP, DIP를 위반한다.
➔DIP : OrderServiceImpl은 DiscountPolicy 인터페이스에 의존하며 DIP를 지킨 것 같지만 자세히 보면 구현 클래스에도 의존하고 있음. DIP 위반
➔OCP: 그래서 RateDiscountPolicy로 변경하려면 OrderServiceImpl의 소스코드도 함께 변경해야 한다. OCP 위반
4.문제점 해결
OrderServiceImpl
public class OrderServiceImpl implements OrderService{
// private final MemberRepository memberRepository = new MemoryMemberRepository();
private DiscountPolicy discountPolicy;
@Override
public Order createOrder(Long memberId, String itemName, int itemPrice) {
Member member = memberRepository.findById(memberId);
int discountPrice = discountPolicy.discount(member, itemPrice);
return new Order(memberId, itemName, itemPrice, discountPrice);
}
}
◾구체에 의존하지 않고 추상화인 인터페이스에 의존하게 코드 변경
◾But 코드를 실행하면? NullPointerException 발생 (discountPoliy를 구체화하지 않았기때문)
➔ 해결방안 : 이 문제를 해결하려면 누군가 클라이언트인 'OrderServiceImpl'에 'DiscountPolicy'의 구현 객체를 대신 생성하고 주입해주어야 함. ---> Configuration으로 해결
// Member.class
public class Member {
//클래스의 멤버변수는 private 처리를 해서 클래스 내에서만 사용 가능하도록, 하지만 getter, setter 를 사용해 외부에서 읽어올 수 있음
private long id;
private String name;
private Grade grade;
public Member(long id, String name, Grade grade) {
this.id = id;
this.name = name;
this.grade = grade;
}
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 Grade getGrade() {return grade;
}
public void setGrade(Grade grade) {this.grade = grade;
}
}
회원 도메인 협력 관계
◾ 클라이언트의 역할 : 회원서비스 호출
◾회원서비스의 역할 : 회원가입 / 회원조희 총 두 가지의 기능을 함
◾회원저장소의 역할 : 세가지 저장소 중 하나를 선택하여 회원 관리
➔ 하지만 [ DB 회원 저장소(자체DB) / 외부 시스템 연동 회원 저장소 ]
이 둘 중 어떤 저장소를 사용할 지미확정이기 때문에
➔ 메모리 회원 저장소를 만들어 개발을 진행한다.(로컬 개발, 테스트 진행용)
회원 도메인 협력 관계
// MemberService.class 회원서비스 역할
public interface MemberService {
void join(Member member);
Member findMember(Long memberId);
}
// MemberServiceImpl.class 회원 서비스 구현체
@Component // 각 클래스가 컴포넌트 스캔의 대상이 되도록 에노테이션을 붙여줌
public class MemberServiceImpl implements MemberService{
private final MemberRepository memberRepository;
@Autowired // 생성자에서 여러 의존관계도 한번에 주입 가능
public MemberServiceImpl(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
} //생성자
/**
* 회원가입
*/
@Override
public void join(Member member) {
memberRepository.save(member);
}
/**
* 회원조회
*/
@Override
public Member findMember(Long memberId) {
return memberRepository.findById(memberId);
}
//테스트 용도
public MemberRepository getMemberRepository() {
return memberRepository;
}
}
// MemberRepository.class 회원 저장소 역할
public interface MemberRepository {
void save(Member member) ;
Member findById(Long memberId);
}
: 저장소는 나중에 교체하기위해 Interface로 추상화 하는건 이해가 가나 Service는 교체 가능성이 없는데 추상화를 하는 이유는? 이 궁금했는데 누군가가 인프런에 질문을 했고, 김영한님이 답변한게 있어서 참조
객체 지향 설계와 스프링 마지막에서 김영한님이 말씀했던 * 이상적으로는 모든 설계에 인터페이스를 부여하자 라는 개념으로 인해 서비스에도 추상화를 사용한 것이다.
실무 고민 * 하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다. * 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고,
향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이다.
강의에서는 이상적으로 역할과 구현을 분리하는 것에 초점을 맞추어서 이런 부분들도 분리했다.
회원 객체 다이어그램
◾ 객체 다이어 그램 : 실제 서버에 올라왔을 때 객체들의 메모리 참조를 그린 것
◾ 결과적으로 우리가 만들어야 하는 그림
2. 회원 도메인 개발
MemoryMemberRepository - 회원 저장소의 구현체
// MemoryMemberRepository.class 회원 저장소의 구현체
@Component // 각 클래스가 컴포넌트 스캔의 대상이 되도록 에노테이션을 붙여줌
public class MemoryMemberRepository implements MemberRepository {
private static Map<Long, Member> store = new HashMap<>();
@Override
public void save(Member member) {
store.put(member.getId(), member);
}
@Override
public Member findById(Long memberId) {
return store.get(memberId);
}
}
💡 궁금증 1
: store를 만들 때 static을 사용한 이유는?
➔ static 을 사용하면 객체를 생성하지 않고 클래스 이름으로 직접 접근할 수 있으며, 오로지단 한 번만 생성되기 때문에 모든 객체에서동일한 값으로 사용할 수 있다.
➔ 따라서다른 객체 간에 값을 전달하거나 공유하는데 용이하다.
➔ 이러한 static의 특징을 이용하여단 하나의 Map을 사용하기 위해static으로 Map을 생성한 것.
➔ 만약 static을 제거한다면 new MemberRepository(); 를 작성할 때 마다 새로운 Map이 생성되어 객체마다 다른 값의 Map을 가지게 된다.
💡 궁금증 2
: store를 HashMap으로 생성했는데 일반적으로 동시성 이슈를 방지하기 위해 ConcurrentHashMap으로 생성하는게 좋다고 하셨다. 예제를 단순하게 하기 위해 HashMap으로 생성했는데 둘의 차이점은?
➔ HashMap과ConcurrentHashMap은 둘다 'key-value' 형태의 데이터를 저장하는 자료구조이다.
HashMap
- 데이터의 삽입, 삭제, 검색등의 연산이 빠르다
- null 값을 저장할 수 있다
- 싱글스레드 환경에서 안전하게 사용할 수 있다
ConcurrentHashMap
- 내부적으로 데이터를 분할하여 처리하기 때문에 멀티스레드 환경해서 HashMap보다 더 빠른 속도로 동작한다.
- null 값을 저장할 수 없다
- 멀티스레트 환경에서 안전하게 사용할 수 있으며 여러 스레드에서 동시에 접근해도 일관성을 유지한다.
MemberServiceImpl
public class MemberServiceImpl implements MemberService{
private final MemberRepository memberRepository = new MemoryMemberRepository();
@Override
public void join(Member member) {
memberRepository.save(member);
}
@Override
public Member findMember(Long memberId) {
return null;
}
}
💡 궁금증 1
: memberRepository를 만들 때 final로 선언한 이유?
◾ 불변성(Immutability): final 필드는한 번 초기화되면 값을 변경할 수 없다. 이것은 필드에 대한 안정성을 제공하며, 필드 값을 보호한다. memberRepository가 한 번 설정되면 다른 객체로 변경되지 않도록 보장한다.
◾ 스레드 안정성(Thread Safety): final 필드는 다중 스레드 환경에서 안전하게 사용된다. 여러 스레드가 동시에 memberRepository를 수정하려고 시도하는 것을 방지하며, 동시 접근에 대한 문제를 방지한다.
◾ 가독성과 유지보수성: final 키워드를 사용하면 코드의 의도가 명확해진다. memberRepository가 한 번 설정되고 변경되지 않는다는 사실은 코드를 읽는 사람에게 중요한 정보를 전달한다.
◾ 오류 방지: final로 선언된 필드는 컴파일 시간에 한 번 초기화되며, 런타임 중에 다시 설정되는 오류를 방지한다.
3. 테스트 코드 작성
위치 중요
◾ 나중에 빌드하면 테스트 코드는 빠진다고 함
MemberServiceTest
public class MemberServiceTest {
MemberService memberService;
// 테스트가 실행하기 전에 무조건 실행
@BeforeEach
public void beforeEach() {
AppConfig appConfig = new AppConfig();
memberService = appConfig.memberService();
}
@Test
void join() {
//given
Member member = new Member(1l, "memberA", Grade.VIP);
//when
memberService.join(member);
Member findMember = memberService.findMember(1L);
//then
Assertions.assertThat(member).isEqualTo(findMember);
}
}
◾ Assertions Import할 때 "import org.assertj.core.api.Assertions;"
💡 궁금증 1
:Assertions의 기능과 assertThat의 기능 종류
➔ Assertions은 테스트 코드에서 사용되며특정 조건이 참이어야 테스트가 계속 진행되도록 하는 기능이며
➔ assertThat은 다양한 비교 및 검증작업을 수행할 때 사용한다.
➔ assertThat 메서드 종류
String ex1 = "hello wolrd";
String ex2 = "hello wolrd";
◾assertThat(ex1).isEqualTo(ex2); /isNotEqualTo(ex1);: 두 값이 같은지 / 다른지 비교
◾assertThat(ex1).isNull(); / isNotNull(); : 값이 null인지 / null이 아닌지 확인
◾assertThat(ex1).istrue(); / isfalse(); : 값이 true인지 / false인지 확인
◾assertThat(ex1).startWith("hello") / endsWith("wolrd") : 문자열의 시작, 끝 확인
◾assertThat(ex1).contains("hello") : 문자열 특정부분에 포함되는지 확인
등등 많으니까 찾아보기
4. 설계의 문제점
◾ 이 코드는 의존관계가 인터페이스 뿐만 아니라 구현체까지 모두 의존하는 문제점이 있음
private final MemberRepository memberRepository = new MemoryMemberRepository();
➔ 여기서 MemberRepository는 인터페이스에 의존하지만 실제 할당하는 부분은 구현체를 의존하고 있음
