Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- SpringDataJPA
- clearAutomatically
- 자바 롬복
- @Modifying
- jpa
- ubuntu
- 우아한테크코스
- @Query
- Mock
- bomblab
- Argos
- 회고
- unique result
- @Param
- 우분투
- 스프링 롬복
- 밤랩
- 영속성컨텍스트
- 우아한테크코스5기
- 우아한테크코스 블랙잭
- 스프링부트배포
- 벌크연산
- 레벨인터뷰
- docker에 ubuntu
- 배포스크립트
- 검색api
- ubuntu이미지
- BDDMockito
- NonUniqueResultException
- 우테코
Archives
- Today
- Total
목록DAO (1)
Jeomxon's Tech Note
DAO와 Repository를 분리했던 이유
문제상황지하철 미션을 진행하면서 db에서 가져온 데이터를 어떤 식으로 다뤄야할지에 대해 많이 고민했다. db에서 데이터를 가져오면서 값을 받아 객체로 넘겨 처리를 할 때 너무 복잡해지고 스스로가 이해할 수 없는 코드가 되고 있었다. 또한 DAO만 사용했을 경우는 Service계층에서 코드가 복잡해졌다. 도메인 엔티티를 만들기 위해서 그에 필요한 많은 로직들이 생기는 경우가 있었다. 특히 연관관계가 있는 경우에는 더 그렇다. 도메인에서 다른 객체의 상태를 가지고 있는 경우 해당 객체도 함께 생성해줘야하므로 코드가 복잡해지게 된다. 사용이유Repository에서 그 책임을 담당한다면 서비스도 당연히 로직이 줄어들고, 도메인을 생성하는 책임이 있다는 것이 명확이 드러나서 훨씬 보기에 편했다. 물론 다른 계층,..
우아한테크코스/프롤로그
2023. 6. 6. 00:30