아무것도 모르는 subray

넣으려는 데이터가 DB에서 Column 의 설정 된 길이보다 길어서 생기는 에러.

Column 길이 늘려주면 그만.

1. BCryptPasswordEncoder 방식

BCryptPasswordEncoder는 Spring Security 프레임워크에서 제공하는 비밀번호 인코딩 및 해싱을 위한 클래스입니다. 이 클래스는 BCrypt 해시 함수를 사용하여 비밀번호를 안전하게 암호화합니다.
BCryptPasswordEncoder를 사용하면 암호화된 비밀번호를 생성할 수 있으며, 생성된 암호화된 비밀번호는 암호 해독이 어렵기 때문에 보안성이 높습니다. 이는 사용자 비밀번호를 저장할 때 보안을 강화하고, 무단 액세스로부터 보호하기 위해 많이 사용됩니다.

2. DelegatingPasswordEncoder 방식

DelegatingPasswordEncoder는 Spring Security에서 제공하는 비밀번호 인코딩 및 해싱을 위한 클래스입니다. 이 클래스는 하나 이상의 PasswordEncoder를 사용하여 비밀번호를 암호화합니다. 주로 여러 가지 비밀번호 해싱 알고리즘을 지원하고자 할 때 사용됩니다.

의존성 추가

implementation 'org.springframework.security:spring-security-core:5.7.1'

내 생각

Spring Security 에서 가장 기본적인 암호화 클래스인 BCryptPasswordEncoder 가 기본이라고 생각하면 되고,

실제로 DelegatingPasswordEncoder 를 쓰더라도 사용자가 알고리즘을 명시해주지 않으면 기본 적으로 BCryptPasswordEncoder 로 선택 돼 사용 된다.

그치만 DelegatingPasswordEncoder 를 쓰는 이유는, 암호화 알고리즘의 변경이 필요할 경우 유연한 선택이 가능하기 떄문.

GPT 에게 한 질문

- 왜 service 계층에서 다시 controller 계층으로 Entity 자체를 넘기는 행위를 지양 해야하는가?

GPT 답변

1. Lazy Loading 문제: Entity는 연관된 다른 Entity를 가지고 있을 수 있습니다. 이 경우, Controller에서 Entity를 반환하면 JSON으로 직렬화할 때 Lazy Loading 문제가 발생할 수 있습니다. 이는 연관된 객체를 가져오기 위해 추가적인 데이터베이스 쿼리가 발생할 수 있으며, 이는 성능에 부정적인 영향을 줄 수 있습니다.
2. API 설계의 일관성: Entity는 데이터베이스 스키마를 나타내는데 사용되므로 API 응답의 형태로 적합하지 않을 수 있습니다. 또한 Entity는 비즈니스 로직을 담지 않고 있는 경우가 많으므로 API의 일관성을 유지하기 어려울 수 있습니다.

• @CreatedDate
  • 데이터 저장 시간 자동 업데이트
• @LastModifiedDate
  • 마지막 수정 시간 자동 업데이트

• @SpringBootTest Annotation
  • 해당 Annotation을 쓰면, @Autowired 를 통해 별도의 의존성 주입 없이 테스트에 필요한 객체를 가져다 쓸 수 있다.
    • AccountService는 AccountRepository 를 주입받고 있기 때문에 연쇄적으로 의존성을 주입해줄 필요 없음.
• @DisplayName()
  •  테스트 목록에 표기 되는 이름을 원하는 이름으로 변경해줄 수 있다.
• @BeforeEach
  • 하위의 테스트들을 실행하기 전 먼저 실행 해주는 로직으로 간편하게 초기값을 세팅해줄 수 있다.
    • ex) 테스트 1의 계좌를 먼저 생성해 id 값 1을 준다.
    • ex) 테스트 2의 계좌를 먼저 생성해 id 값 2를 준다.
    • BeforeEach 가 없다면 여러개의 테스트에 계좌를 생성하는 로직을 모두 포함 시켜줘야함.

• @ExtendWIth(MockitoExcention.class)
  • Mockito 사용을 위한 Annotation
  • @Mock
    • 주입 시켜야할 Mock 만들기
  • @InjectionMocks
    • 위에서 만든 Mock 을 해당 객체에 주입 하기

이후 해당 Mock을 통한 테스트 진행 가능

• 유틸리티 클래스란 ?
  •  주로 정적(static) 메서드로만 이루어진 클래스를 뜻한다.
    • 객체의 생성 없이 사용 가능
    • 특정 작업을 수행하는 메서드를 제공 (여러곳에서 반복적 사용이 가능)
    • 인스턴스화 방지, 인스턴스 생성이 필요 없기 때문에 유틸리티 클래스의 생성자는 private 으로 선언 되거나 클래스를 final로 선언하여 상속을 막는다.
• @UtilityClass Annotation
  • 유틸리티 클래스를 간편히 사용할 수 있게 해주는 Annotation
    • 생성자를 기본 private으로 설정 해준다.
    • 모든 메서드를 static 으로 자동 설정해준다. (위의 예시에서는 static이 쓰여있다. 읽는 이로 하여금 더 명확한 표현 제공을 위해 적어두었지만 UtilityClass Annotation을 사용 할 경우 적지 않아도 무방하다.)
    • final 클래스로 만들어 상속을 막아준다.
    • 클래스에 대한 기본 생성자를 생성하지 않으므로, 코드가 더 간결해진다.