J의 개발자 공부

적용@Entity : JPA가 사용하는 객체@Id : 테이블의 PK와 해당 필드를 매핑@GeneratedValue(strategy = GenerationType.IDENTITY) : PK 생성 값을 데이터 베이스에서 생성@Column : 객체의 필드를 테이블의 컬럼과 매핑>> 생략할 경우 필드의 이름을 테이블 컬럼으로 사용 JPA는 public 또는 protected의 기본 생성자 필수 스프링을 통해 EntityManager를 주입 받음>> JPA의 모든 동작은 엔티티 매니저를 통해 이루어짐>> 엔티티 매니저는 내부에 데이터 소스를 가지고 있고 데이터 베이스에 접근 가능 @Transactional>> JPA의 모든 데이터 변경은 트랜잭션 안에서 이루어져야 함 JPA에서 객체를 테이블에 저장할 때는 엔티티..

MyBatisSQL을 XML에 편리하게 작성 가능XML에 작성하기 때문에 라인이 길어져도 문자 더하기에 대한 불편함 x 동적 쿼리를 편리하게 작성 가능 적용MyBatis 매핑 XML을 호출하는 Mapper 인터페이스>> 인터페이스의 메서드를 호출하면 xml의 해당 SQL을 실행하고 결과를 돌려줌 id는 매퍼 인터페이스에서 설정한 메서드 이름 지정파라미터는 #{} 문법 사용, 매퍼에서 넘긴 객체의 프로퍼티 이름을 적어줌>> preparedStatement 사용, JDBC의 ?를 치환한다 생각useGeneratedKeys는 데이터베이스가 키를 생성하는 IDENTITY 전략일 때 사용>> keyProperty는 생성되는 키의 속성 이름 지정, Insert 끝나면 item 객체의 id 속성에 생성된 값 입력됨..

데이터 베이스 분리로컬에서 사용하는 애플리케이션 서버와 테스트에서 같은 데이터베이스를 사용해서 테스트에서 문제 발생 테스트 전용 데이터베이스 별도 운영(가장 간단한 방법)jdbc:h2:tcp://localhost/~/test (local에서 접근하는 서버 전용 데이터베이스)jdbc:h2:tcp://localhost/~/testcase (test 케이스에서 사용하는 전용 데이터베이스) 테스트는 다른 테스트와 격리해야 함테스트는 반복해서 실행할 수 있어야 함 데이터 롤백테스트가 끝나고 트랜잭션을 강제로 롤백하면 데이터가 깔끔히 제거 @Transactional스프링은 테스트 데이터 초기화를 위해 트랜잭션을 적용하고 롤백하는 방식을 @Transactional 로 깔끔히 해결 @Transactional 애노테이션..

JdbcTemplate장점설정의 편리함>> spring-jdbc 라이브러리에 포함(스프링 기본 라이브러리)>> 별도 설정 없이 바로 사용 가능 반복 문제 해결>> 템플릿 콜백 패턴을 사용 대부분의 반복 작업 대신 처리>> 개발자는 SQL 작성, 전달할 파라미터 정의, 응답 값 매핑만 단점동적 SQL 해결 어려움 이름 지정 파라미터NamedParameterJdbcTemplate이라는 이름을 지정해서 파라미터를 바인딩 하는 기능 제공 파라미터를 전달하려면 Map처럼 key, value 데이터 구조를 만들어 전달해야 함여기서 key는 :파라미터이름 으로 지정한 파라미터의 이름이고 value는 해당 파라미터의 값 Map단순히 Map 사용 MapSqlParameterSourceMap과 유사하지만 SQL 타입을 ..

SQL MapperJdbcTemplate, MyBatis 개발자는 SQL만 작성하면 해당 결과를 객체로 편리하게 매핑JDBC를 직접 사용할 때 발생하는 여러가지 중복 제거, 기타 편리한 기능들 제공 ORMJPA, Hibernate, 스프링 데이터 JPA, Querydsl 기본적 SQL은 JPA가 대신 작성하고 처리저장하고 싶은 객체를 마치 자바 컬렉션에 저장하고 조회하듯 사용하면 ORM 기술이 데이터베이스에 해당 객체 저장하고 조회 프로필스프링은 로딩 시점에 application.properties의 spring.profiles.active 속성을 읽어 프로필로 사용>> 로컬, 운영 환경, 테스트 실행 등 환경에 따라 다른 설정을 할 때 쓰는 정보>> 로컬 PC에서는 PC에 설치된 데이터베이스에 접근해야..

데이터 접근 예외 직접 만들기데이터베이스 오류에 따라 특정 예외는 복구하고 싶을 수 있음데이터를 DB에 저장할 때 같은 ID가 이미 데이터베이스에 저장되어 있으면>> 데이터 베이스는 오류 코드를 반환하고 JDBC 드라이버는 SQLException을 던짐>> 여기에는 데이터베이스가 제공하는 errorCode 들어있음 스프링 예외 추상화스프링은 데이터 접근 계층에 대한 수십 가지 예외를 정리해 일관된 예외 계층 제공각 예외는 특정 기술에 종속적이지 않게 설계JDBC나 JPA를 사용할 때 발생 예외를 스프링이 제공하는 예외로 변환하는 역할도 제공 NonTransient 예외>> 일시적, 동일 SQL를 다시 시도했을 때 성공 가능성>> 쿼리 타임아웃, 락과 관련된 오류들 Transient 예외>> 일시적 x, ..

기본 원칙 2가지기본적으로 언체크(런타임) 예외 사용 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자>> 반드시 처리해야 하는 예외일 때>> 계좌 이체 실패, 결제시 포인트 부족, 로그인 ID PW 불일치>> 체크 예외로 만들어 두면 컴파일러를 통해 놓친 예외 인지 가능 체크 예외 활용왜 언체크 예외가 기본?복구 불가능한 예외대부분의 예외는 복구 불가능>> SQLException 같은 예외는 데이터베이스에 문제가 있어 발생하는 서비스나 컨트롤러에서 복구 불가능한 예외의존 관계에 대한 문제처리할 수 없는 예외이기 때문에 계속해서 throws를 통해 예외를 던져야 함>> 리포지토리를 JDBC 기술이 아닌 다른 기술로 변경하면 예외의 의존을 변경해야 함 (서비스 코드 수정 필요) 언체크 예외 ..

트랙잭션 문제JDBC 구현 기술이 서비스 계층에 누수되는 문제>> 구현 기술을 변경해도 서비스 계층 코드는 최대한 유지할 수 있어야 함(변화에 대응) 트랜잭션 동기화 문제>> 같은 트랜잭션을 유지하기 위해 커넥션을 파라미터로 넘겨야 함>> 똑같은 기능도 트랜잭션용 기능과 트랜잭션을 유지하지 않아도 되는 기능으로 분리해야 함 트랜잭션 적용 반복 문제>> try, catch, finally 예외 누수데이터 접근 계층의 JDBC 구현 기술 예외가 서비스 계층으로 전파되는 문제>> SQLException은 JDBC 전용 기술, 향후 데이터 접근 기술이 바뀌면 서비스 코드 수정 필요 JDBC 반복 문제유사한 코드의 반복 문제>> try, catch, finally>> 커넥션 열고 PreparedStatement..