이거는 팁인데
면접보는 개발자나 잘하는사람들은
============================================
라이브러리에 의존을 최소화하려고 노력한 프로젝트들이 거의 없다 신입은
라이브러리를 자체 제작하려고 노력한다
===========================================
어떤 버전에 대한 호환성
외부 라이브러리에 의존하지 않고 개발 해보려고 했다
디펜던시 오류들도 발생할수잇으니까
jpa를 사용하긴 사용하되 entity클래스를 일체하게끔 유지하면서 테이블에 대한 이해도를 높이고 싶었다
데이터베이스에 대해 이해도가 올라갈 것 같아서
의존도 = jpa 쓰지 말아야지 가 된다
jpa에 너무 의존하고 있는 거 같아
데이터베이스 학습을 덜하게 되어서 하게 되었다
지금 이해도가 제일 높으니까 문서로 정리 해놔라
의존을 뺄 수 있으면 빼자
왜냐하면 문제가 될 수도 있으니까
웹 종속성을 없앨라고 웹 레이어랑 도매인 레이어랑 나누기도 했었고 = 배민스타일(극단적으로 나누는거 좋아함)
-> ? 이렇게 안하고 dto로 안받고 해결할수 있는 방법이 있을까?
=> 뭐든지 서사가 있으면 된다
다른 ORM이 등장했을때 이거또한 같은 방식으로 접근하면 좋다.
의존하지 않고 개발해보려고 했다
=> 어떻게보면 나도 알고리즘할때 함수같은거 안쓰고 하려고 하는 그런느낌??
DTO로 변환하는거 : JPQL으로 변환한것
결국 완전한 NATIVE 쿼리는 아니다
동하님 피드백 정리
원빈 튜터님 피드백
라이브러리에 의존하고 싶지 않았다 -> 그럼 jpa를 아예 쓰지 말아야지 -> 이러기 전에 jpa라는 ORM이 아니라 다른 프레임워크로 개발하는 상황이 왔을 때 테이블 자체에 대한 이해도가 떨어지는 것 같았다. 그래서 엔티티와 테이블이 비슷한 형태를 가지게끔 했다... (의존하지 말아야지 라고 하면 왜 jpa 공격당하니까 의존도라는 생각을 했고 DB스러운 개발을 해보고 싶었다.)
OrderGameGetDTO -> 영속성 레이어까지 다 들어온 것이다. 이게 jpa에서 추가한 거긴 떄문에 의도한 것은 맞지만. 개인적으로는 최소한 의존을 빼면 좋겠따.
잭슨까지는 직접 구현하지 마라. Spring이 선택한 라이브러리다. Spring은 종속이라 보면 안되기 때문에 잘 선택해라.
==============================================
웹 종속성 : 웹에서 요구하는 스펙이 변경되었을 때
예) ~는 빼고 보내라
-> 그럼 SQL이 변해야 한다!
그럼 우리 코드(REPOSITORY)가 변경되어야한다? -> 이건 말이 안된다
DAO가지고 DTO를 만들어야지 REPO에서 DTO를 만들어서 주면 안된다는것
웹의 스펙에 따라 골라가던가 해야지 DTO를 박아버리면 안된다
만약에 무수하게 많은 웹의 요청이 다 다르면?
이 똑같은걸 5~6개 만들어야함
-> 이건 말이 안된다!!!
그래서 웹에 따라 변경하는 로직을 만들거나 해야함
! 그래서 DTO를 ENTITY에다가 넣지 말라는것
! 절 대 종속, 의존되게 만들지 마라
? 그럼 요청마다 스펙이 달라지면 어떻게 만들어야 할까?
그래서 어떻게 했냐면
===================
웹 레이어와 도메인 레이어 분리
- 컨트롤러 딴에서 유저가 가입을 함
- 서비스 메서드 여러개 만들지 말고
- WEB 레이어에서 가공을 한번 거쳐서 다음 DOMAIN레이어로 넘긴다 -> 순수한 엔티티만 던져준다
WEB 컨트롤러 -> WEB SERVICE에서 변환(TO ENTITY) -> DOMAIN SERVICE에서 받고 -> 레포 저장
-> 창현님 글
https://velog.io/@thsckdgus9/%EB%8F%84%EB%A9%94%EC%9D%B8-%EB%A1%9C%EC%A7%81%EC%9D%98-DTO
깃허브 PPT 참고하기
JPA의 의존성을 줄이기 위해서 객체 그래프 탐색할 때 발생하는 쿼리를 예상하고 그것을 우리가 SQL로 직접 작성하여 실행함으로서 종속성을 그나마 제거했다(DTO로 변환하는거 : JPQL으로 변환한것 결국 완전한 NATIVE 쿼리는 아니다)
그러면 JPA말고 JDBC를 써서 JPA를 아예 안쓰면 된다. 이걸 왜 JPA종속성을 추가했나?
그러면 할말이 없다
근데 우리는 그런 의도가 아니다. JPA를 쓰다보니까 데이터베이스 테이블에 대해서 지식이 좀 얕은것같아서 최대한 JPA를 사용하면서 연관관계 형성을 하지 않고 외래키 값만을 필드로 두면서 우리가 사용하는 RDB의 형태로 유지하여 개발을 진행했다.
보통 입문자들은 뭔가 기능이 필요하면 외부 라이브러리를 그냥 무작정 사용을 하는데 이렇게 되면 문제점이
1. 이런 라이브러리에 너무 의존을 하게 되는것이고
2. 만약에 스프링 버전을 업그레이드 해야한다? 어떤 라이브러리는 스프링 버전 업그레이드에 대한 호환을 맞춰주는데도 있지만
아닌 라이브러리도 있을 수 있어서 이런게 발목잡힐 수 있다.
Component, Lombok 등 사용 이유와 내부 구조, Springboot의 실행 과정 등등 자세히 뜯어봐야할게 너무 많다!
