⚡ 생각대로 살지 않으면 사는대로 생각한다.
⚡ 나는 어차피 잘 될 놈이다. 이미 잘 되고 있고, 계속해서 잘 되고 있다.
🤔Setter에 대한 언급
Setter를 만들면 아무 곳에서나 수정할 수 있으니, 코드추적이 쉽지 않다. 유지보수성이 떨어질 수 있다.
가급적이면 생성자를 통해서 값을 세팅하고,Setter의 사용을 최소화하는 것이 유지보수에 용이하다.
혹시나 H2 잘 안 되면 여기 참고 !!
✅관례상 DB는 언더바를 많이 사용하고, Java는 카멜케이스를 사용한다.
예시 Member의 Id를 줄 때
DB Java member_id or MEMBER_ID memberId 애매하면, 직접 매핑해주면 된다.
스프링 부트에서는 Java에서 camelCase로 작성한 부분을 소문자 & 언더바로 바꿔주는 설정을 기본으로 가져간다.
🤔만약, SQL쿼리에서 메타데이터가 별로 맘에 들지않으면, 선택에 따라 상황에 맞게 해주면된다.
영한좌는 제약사항들을 다 명시해주는 편이다.
왜냐하면 엔티티만 봐도 테이블의 제약사항들을 볼 수 있고, 굳이 DB를 까보지 않아도 되기 떄문이다.
JPQL을 작성할 때도 테이블을 왔다갓다 하면서 보고 작성하는 것보다는 엔티티 객체만 보고도 작성할 수 있기 때문이다.
위에 처럼 엔티티를 설계하면, 아래처럼 코드를 작성하게 되는데,
객체 지향적이지 못한 느낌이 강하게 든다.
객체는 객체 그래프로 참조에 잠조하며 찾아갈 수 있어야하는데, 이런식으로 하게되면, 중간의 연결이 끊기게 된다.따라서 아래와 같이 코드를 작성하면,
밑에 코드처럼 깔끔해진다...
문제가 되었던 설계방식을 데이터 중심 설계라고 한다.
데이터 중심 설계의 문제점
- 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
- 테이블의 외래키를 객체에 그대로 가져옴
- 객체 그래프 탐색이 불가능
- 참조가 없으므로
UML도 잘못됨- 참조가 끊김.
그래서 이런 문제를 해결하기위해 다음 파트가 연관관계 매핑 기초이다...
가슴이 웅장해진다...❗❗
-끝-
