태초에 다른 회사에서 만든 EJB가 있었는데~~~ 너무 싫어서 스프링 만들었는데~~~... 오픈소스로써 직접 만든 하이버네이트가 공식이 되어 오픈소스 출신이라 현업에 아주 잘 맞는다는 특징. JPA가 공식으로 인수해감. 고전적인 데이터베이스와 신흥 데이터베이스들이 나왔지만 결국엔 어딘가에 데이터를 저장하고 가져오는게 전부다. 그럼 하나의 거대한 인터페이스로 추상화할 수 있지 않을까? 해서 나온게 Spring Data고 그걸 다루는게 Spring Data JPA(아마 맞을듯). 그럼 Spring Data만 알면 모든 DB 다 다룰수 있네? 몰라도 되겠네?? 가 아니다. 편리하게 해주는 도구일 뿐이지 내부가 어떻게 돌아가는지 모르는건 자바를 모르는 채로 스프링을 쓰는 거임. 작은데든 큰데는 왠만하면 다 이렇..

이제 sql문을 자동으로 해주는 ORM인 JPA를 사용할 건데 내용이 엄청 방대에서 왜 필요한지랑 큰 그림만 볼거다. 정말정말 많이 쓰인다. 그 전에 ORM이 뭔지부터 알아보자. 대충 적을거. ORM은 Object-Relational Mapping의 줄임말인데 자기가 사용하는 언어의 객체(여기선 자바)로 정의하면 ORM이 알아서 sql문을 짜줘서 db에 명령한다. 이 역할을 자바 진영에서 수행하는게 JPA(Java Persistence API)이고 JPA가 자바 진영의 ORM 표준이다. 표준이 중요한 이유는 스프링에서 보장해준다는거. 이게 정말 좋은 이유는 기존에 개발자들은 무슨 객체를 만들고 정의하려고 해도 db의 sql문까지 고려하면서 만들어야 되기 때문에 불편한것도 있지만 객체지향적으로 생각을 못하..

MyBatis가 뭐냐면 jdbcTemplate의 기능들도 포함하며 동적쿼리 등에서 더 편리하게 작성할 수 있는 SQL Mapper이다. 가장 매력적인건 sql을 xml에 편리하게 작성할 수 있고 동적쿼리도 편리하게 작성할 수 있다 함. 작성은 편리하지만 jdbcTemplate는 기본적으로 들어있어 그냥 사용할 수 있는 반면 MyBatis는 사용하려면 약간의 설정이 필요하다. 사실 왠만하면 JPA같은 ORM도 왠만큼 복잡한 동적쿼리 같은것도 지원해서 가끔 sql을 쌩으로 작성해야 될 때 jdbcTemplate로 대부분 처리가 가능하다고 한다. 하지만 MyBatis를 사용해도 좋고 둘다 써도 상관없다. 그냥 좋을대로 쓰면 된다. MyBatis – 마이바티스 3 | 소개 MyBatis – 마이바티스 3 | 소..

mybatis 하기 전에 테스트 코드에 db와 연결해서 하는 방법을 알아볼거다. 메인의 설정 파일에 url을 db에 연결했던것 처럼 test 패키지에 test용 프로퍼티를 만들면 그거 따라 진행된다. @SpringBootTest class ItemRepositoryTest { @Autowired ItemRepository itemRepository; @AfterEach void afterEach() { //MemoryItemRepository 의 경우 제한적으로 사용 if (itemRepository instanceof MemoryItemRepository) { ((MemoryItemRepository) itemRepository).clearStore(); } } @Test void save() { //..

만약 SQL을 직접 작성한다면 JdbcTemplate는 좋은 선택이다. jdbc를 깔면 spring-jdbc라이브러리를 사용할때 기본적으로 jdbc를 사용하는데 안에 같이 들어있고 세션문제, 트랙잭션 문제, 반복코드 작성 등을 알아서 해결해주기 때문. gradle 설정 파일에 해당 라이브러리를 설치하고 사용한다고 설정하면 된다. 테이블은 직접 만들어야 한다. id에다가 generated by default as identity를 사용하는데 그냥 저장만 하면 db보고 알아서 고유값을 만들어달라고 하는거다. 여기선 단순 숫자 증가만 할거임. /** * JdbcTemplate */ @Slf4j public class JdbcTemplateItemRepositoryV1 implements ItemReposito..

섹션 0 내용 이하 섹션1 앞에서 핵심 원리를 배웠으니 이번엔 진짜 여러 DB를 가지고 사용해본다. 기술을 SQLMapper, ORM 관련 기술로 2가지로 나눌 수 있는데 SQL Mapper는 내가 sql문을 직접 짜면 알아서 변형해줘서 실행하는거라 빠르게 하고 세세한 커스텀으로 jdbc로 했을때 생기는 중복을 방지 가능. ORM 주요 기능은 일반 객체 정의할 때 처럼 정의만 하면 ORM이 알아서 DB에 sql문 쳐줘가지고 일반 자바 객체 다루듯이 할 수 있다. JPA를 사용하면 기본적인 SQL은 JPA가 대신 작성하고 처리해준다. JPA는 자바 진영의 ORM 표준이고 Hibernate가 제일 많이 사용되는 JPA의 구현체이다. JPA를 인터페이스, Hibernate를 실체화된 객체라고 생각하면 된다 함..

이제 만들었던 프로젝트에 적용할건데, 컨트롤러에 인터페이스를 사용할거다. 왜 갑자기 사용하냐면 원래 사용할 수 있었지만 인터페이스로 정의한 함수 뒤에 extends throws 해서 덕지덕지 붙이는게 싫어서 그냥 안만들고 쌩 클래스로 한거임. 그래서 이번에 예외처리에서 throws 없애는 김에 인터페이스로 구현하는 거다. 원래는 체크 예외인 SQLException을 런타임 예외로 바꾸기 위한 런타임 예외 db 클래스를 따로 만들자. /** * 예외 누수 문제 해결 * 체크 예외를 런타임 예외로 변경 * MemberRepository 인터페이스 사용 * throws SQLException 제거 */ @Slf4j public class MemberRepositoryV4_1 implements MemberRe..

앞으로 스프링에서의 예외 배울 건데 개념을 짚고 넘어가자. 자바의 모든 객체는 항상 Object가 부모다. 이건 예외 클래스도 마찬가지. 단지 예외 클래스 시작은 Throwable부터 시작한다고 보면 된다. 여기서 Exception과 Error 자식 클래스로 나뉘는데 Error클래스는 메모리 초과나 컴퓨터의 심각한 오류같은 것이기 때문에 잡으면 안되고 그냥 생기도록 그대로 두어야 한다. 무리해서 더 진행하면 컴퓨터 망가지겠지? 그럼 Exception부터 애플리케이션 관리 영역이다. 실행 전 컴파일러가 잡을 수 있는 에러를 체크예외, 실행 중에 잡을수 있는 에러를 언체크 예외 또는 런타임 예외라고 하는데, Exception부터 자식들은 모두 체크예외지만 그의 자식인 RuntimeException만 예외라고..

지금까지 만든 애플리케이션의 문제점을 보자. 애플리케이션 구조는 정해진게 없지만 주로 프레젠테이션, 서비스, 데이터 접근 계층 3가지로 나뉜다. 중요한건 서비스 계층에선 다른 라이브러리등에 의존하지 않고 순수 자바코드로 작성하는 것이다. 그래서 로직을 위한 매개변수를 받기위한 http 통신 사전작업, db에 저장 및 조회를 위한 사전작업 및 더러운 작업들은 모두 프레젠테이션 계층이나 데이터 접근 계층에 맡기고 서비스 계층은 순수한 상태를 유지해야 핵심 서비스를 파악하기 쉽고 유지보수에 용이하다. 근데 현재 우리의 서비스를 봐라 커넥션 때문에 서비스 클래스 안에 db의 라이브러리들이 잔뜩 들어가 있다. 물론 커넥션을 여기서 만들어서 트랜잭션을 관리하는건 맞다. 하지만 순수한 자바의 형태를 유지하지 못하게 ..

일반 메모장 같은걸로도 저장은 할 수 있다. 근데 하필 왜 데이터베이스를 쓰는가? 그건 트랙젝션을 지원하기 때문이다. 거래인데, 안전하게 거래를 해주는걸 보장해준다. 애초에 거래라는게 하나처럼 보여도 사실 여러개다. 예를들어 A가 B에게 5000원을 입금했을 때 현실로는 그냥 지폐 5000원 주면 되지만 디지털로는 A의 계좌에 5000원을 감소시키고 B의 계좌에 5000원을 증가시키는 2가지 일을 동시에 수행한다. 그럼 만약 A의 계좌에 5000원을 감소시키는건 성공했지만 B의 계좌에 5000원을 증가시키는걸 실패했다면?? 걍 중간에 돈이 날라가고 매우 큰 법적 문제가 생길 수 있음. 그래서 이런 거래를 하나의 작업처럼 만들어서 정상 반영하는걸 커밋(commit)이라고 하고 하나라도 실패해서 거래 이전으..