Repository가 @SpringBootApplication이 선언된 클래스의 패키지 혹은 그 하위 패키지에 위치하고 있는지 확인하세요.
-> 즉, 컴포넌트 스캔 범위에 벗어났다..
꼭 확인하세요...
잘모르는 스린이 왜이러지 하다가 1시간 반 날렸어요 ㅎㅎㅎㅎ하하하하
Entity 설계시
Entity 클래스는 데이터베이스와 매핑되어 데이터를 영구적으로 저장하는 역할을 수행합니다. 따라서 Entity 클래스의 필드는 데이터베이스 테이블의 컬럼과 직접적으로 매핑되며, 이는 데이터베이스 설계에 영향을 받습니다.
반면에 요청(Request)와 응답(Response)용 클래스는 클라이언트와 서버 간의 통신을 위한 계약(API Contract)을 정의합니다. 이 계약은 데이터베이스 설계와는 무관하게 독립적으로 변경될 수 있습니다.
Entity 클래스를 Request나 Response 클래스로 사용하면 다음과 같은 문제점이 발생할 수 있습니다:
데이터 노출 문제: 클라이언트에게 보여줄 필요가 없는 정보까지 노출될 수 있습니다. 예를 들어, 비밀번호 해시나 내부적으로 사용하는 ID와 같은 민감한 정보가 포함될 수 있습니다.
유연성 저하: Entity 클래스는 데이터베이스 테이블 구조에 맞춰 설계되기 때문에, 클라이언트의 요구사항에 따라 유연하게 응답 구조를 변경하기 어렵습니다. 이는 클라이언트와 서버 간의 통신에 필요한 유연성을 저하시킵니다.
성능 문제: Entity 클래스를 그대로 반환하면, LAZY 로딩을 사용하는 연관관계가 모두 초기화되어 쿼리가 불필요하게 발생할 수 있습니다. 이는 애플리케이션의 성능을 저하시킵니다.
따라서, 요청과 응답을 위한 별도의 DTO(Data Transfer Object)를 사용하는 것이 좋습니다. DTO는 클라이언트와의 통신을 위한 계약을 명확하게 정의하고, 필요한 데이터만을 포함하여 통신의 효율성을 높이며, 도메인 모델을 숨기는 역할을 합니다. 이를 통해 애플리케이션의 유연성과 보안성, 성능을 향상시킬 수 있습니다.
Repository
MyBatis에서는 Dao 라고 불리는 DB Layer 접근자
JPA 에서는 Repository 라고 불리고 인터페이스로 생성.
단순하게 인터페이스 생성 후, JpaRepository<Entity클래스, PK타입> 을 상속하면 기본적인 CRUD 메소드가 자동으로 생성
@Repository도 필요없음.
-> 설계시 Entity 클래스와 기본 Repository는 함께 움직여야 하므로 도메인 패키지에서 함께 관리.
