DevBoi

일단 기본적인 구조는 아래와 같다 Controller > Service > Repository 이외 해당 API에 대한 설명은 스웨거로 작성을 하였고 게시물, 회원에 대한 간단한 Controller,Service, Repository는 아래와 같다. 소스 코딩은 별로 하지 않았고, 시간도 적었다. 러닝 커브는 심하지만, 이러한 JPA의 장점과 좋은 점들을 최대한 활용해보고자 하였고 추후에 QueryDsl 까지 섞어서 개발을 진행할 예정이다. 또한 트랜잭션 관련 개발 내용도 구조와 개념을 상세히 스터디해서 포스팅 할 예정이다. 공부의 의미가 적은 비즈니스로직은 사실 일일히 포스팅 할 필요가없어서 구조에 대한 개념을 잡기위해 아래와 같이 대충 포스팅 ㅋ

DTO와 Entity 간의 설정은 JPA에서 필수 조건이라고 생각한다. Entity를 DTO처럼 사용한다면, 나도 모르는새에 트랜잭션이 닫히면서 디비로 쿼리가 나갈수도있고 데이터가 바뀔수도 있기 때문이다. 이전에는 ModelMapper라는 기능을 사용했지만 이건 생각 보다 단점이 많은 기술이다. 쓰면서도 대충 느낌이 오긴했지만, 자세히 안좋은 점들과 어떨때 쓰면 좋을지는 추후 포스팅에서 다루기로 하고 일단 바꾼 방식에 대해서 정리해보자 일단은 빌더 패턴이다. 엔티티에서는 dto를 파라미터로 받아서, 세팅해주는 빌더를 선언해준다. 실제로 다 빌더로 넣어줄수도있지만, postId같이 자동으로 seq같이 붙는 값을 관리해주기위해 해당 유형의 값은 빼고 관리해주자 DTO에서는 이렇게, getEntity라는 메소..

도메인은 우선 기본적으로 크게 4가지로 잡았다. User - 사용자 Post - 게시물 master PostContent -게시물 요청자 PostComment - 게시물 작업자 Asset - 자산 자산은 이력성으로 쌓고, 게시물도 이력성으로 쌓을 것이다. 그이유는 스케줄러나 배치로 주기적으로 회원들 정보를 갱신해주는것도 좋지만 그렇게 많은 사람들의 작업이 있지않는 이상,이를 굳이... 뭐 나중에 데이터가 점점 쌓이면 등급에 대한건 그떄 고민해보자 스케줄러던 배치던 무튼 이렇게 4개에 대한 도메인을 설계했고, 해당 관련 개발까지 머리속으로 설계는 끝냈다. 사실 개발하는것 자체보다 설계에 시간을 많이 쓰긴했다. 이 모델 기반으로 JPA를 설계할 것이고 개발해 나갈 것이다. mybatis를 쓸까 고민도 하긴했..

최근 사이드 프로젝트를 계속 진행하면서, 뭔가를 정리할 시간이 없었다... 뭔가 알고는 있었지만 계속 찾아서 써먹는 ModelMapper에 대해서 정리를 해보려고한다. 잘알다 싶이, JPA에서 사용하는 Entity는 DTO로 사용하면 절대 안된다. 쉽게 얘기하면, DB layer와 view layer에서 각각 엔티티와 DTO를 다르게 사용해야한다. 이유는 다양하지만, JPA특성상 엔티티의 값을 set하고, save하면 자동으로 디비 쿼리가 나가기 때문에가 가장 크다고 생각한다. Entity를 Dto처럼 쓴다면, 추후 운영 상에 디비에 대한 정보를 의도치 않게 바꿀수 있다. 그래서 Entity와 Dto를 분리해야하는데, Entity로 정보를 얻고, 이걸 Dto로 변환하려면 어떻게 해야할까? ModelMap..

프로젝트의 진행이 조금 더뎌졌다... 이직과 이직한 회사에서의... 신규 기술 학습으로 인해... 무튼 오늘 진행한 내용 별건없지만, 다시 마음을 다잡기로 해서, 다시 첫번째 커밋을 진행하였다. 1) 모델 구현 admin, user admin은 패스워드와 , 아이디 user는 대기를 등록하고 알림메시지를 받을 모델로 구현했다. 자체적으로 PK는 시퀀스로 등록을 했고, admin 의 id,pw는 서로 validation체크를 하지 않게끔 우선은 설계를 하였다. 넣을때 해도되고, 아니면 PK를 추가적으로 잡아도되니... 우선 이렇게 진행을 하기로하였다. 2) 초기 로드시, 기본 관리자 계정 생성 어떻게 보면, 슈퍼 admin이다. 로드할때 특정 아이디와 비번으로 계정을 생성한다. 이는 메모리 디비이기 때문에..

JPA에서 해당 PAGE 기능을 개발하려고하면, 해당 과 같이 사용하면 된다. 좀 더 자세히 공부를 해보도록 하자

낙관적 락 일단, 트랜잭션 충돌이 발생하지 않는다고 가정한다. DB가 제공하는 락을 사용하지 않고, JPA가 제공하는 Version 관리을 사용한다 트랜잭션을 커밋하기 전까지 충돌을 알수 없다. 낙관적락 이렇게 메소드에서 사용할 수 있다. 해당으로 사용하게 되면, 트랜잭션이 커밋될때, version을 업데이트하게 된다. @Version으로 명시된 컬럼이 증가하게되고, 해당 증가후에 트랜잭션이종료하게 된다. 만약에 다른 트랜잭션에서 어떤값을 수정하려고할때, 해당 버전에 대한 값을 확인후에, 버전이 같으면, 수정 다르면 예외를 발생시킨다. LockModeType 중에 OPTIMISTIC_FORCE_INCREMENT가 있다. 해당 방식일때는 조회만으로 version이 update된다. update 도 vers..

플러시 (Flush) -영속성 컨텍스트의 변경 내용을 DB에 반영하는 것을 말한다. -Transaction commit 이 일어날때 flush가 동작하는데, 이때 쓰기 지연 저장소에 쌓아놨던 insert, update,delete sql들이 DB에 날아간다. (영속성 컨텍스트를 비우는 건아니다) -영속성 컨텍스트의 변경사항들과 DB의 상태를 맞추는 작업이다. (영속성 컨텍스트의 변경 내용을 DB에 동기화한다.) 플러시 동작 과정 1. 변경을 감지한다 (Dirty checking ) 2. 수정된 Entity를 쓰기 지연 SQL 저장소에 등록한다. 3. 쓰기 지연 SQL 저장소의 Query를 DB에 전송한다. Flush 발생한다고 해서, commit 이 이루어지는 것은 아니고, Flush 이후에 commit..

격리성은 동시에 실행되는 트랜잭션이 서로에게 영향을 미치지 않도록 격리한다. 격리 수준에는 다음과 같다 * READ UNCOMMITED(커밋되지 않는 읽기) 트랜잭션 A가 특정 컬럼 데이터를 변경하고 있는 중에, 트랜잭션 B가 read하면, A가 변경한 데이터를 읽어온다. -문제 : dirty read, 트랜잭션 A가 특정 컬럼 데이터를 변경하고 rollback했을때 발생한다. * READ COMMITED(커밋된 읽기) 트랜잭션 A가 특정 컬럼 데이터를 변경하고 있는 중에, 트랜잭션 B가 read하면 트랜잭션 A가 변경하기 전 데이터를 읽어온다. 만약 트랜잭션 A가 데이터 변경후, 커밋하게되면 트랜잭션 B는 변경된 데이터를 읽어온다. -> 즉, 한트랜잭션 내에서 외부 요인의 데이터 변경 커밋이 반영되어 ..

JPA : java persistence api 약자, 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스이다. Hibernate : jpa의 구현체이다.