옛날에야 저장소를 직렬화 데이터도 쓰고 문자열로도 쓰고 뭘로 쓸지 모르니까 저장소라는 개념으로 추상화시켜서 인터페이스로 썼었지만
지금은 무조건 db를 쓰는데 굳이 인터페이스로 만들어 분리할 필요가 없다는 주장이 닷넷 사용자 사이에서는 다수설인가봄
옛날에야 저장소를 직렬화 데이터도 쓰고 문자열로도 쓰고 뭘로 쓸지 모르니까 저장소라는 개념으로 추상화시켜서 인터페이스로 썼었지만
지금은 무조건 db를 쓰는데 굳이 인터페이스로 만들어 분리할 필요가 없다는 주장이 닷넷 사용자 사이에서는 다수설인가봄
ㅇㄱㄹㅇ
테스트 때문에 분리하능거 아님? - dc App
그게 repository 패턴으로 분리했을때의 장점중에 하나긴 한데, 애초에 repository에서 찾아오는 데이터가 엔드유저한테 전달되어야 하는 최종 데이터와 거리가 먼 경우도 많고 다른 엔티티와 조합된 데이터인 경우도 많은데, 그때마다 repository 레이어를 각각 찾아가서 약간씩 손봐야 하는 번거로움이나
거기다가 db 연결을 위한 프레임워크를 교체하는 일은 실무에서 발생할 수가 없는데, ddd 책 읽어봐도 이걸 교체하는 상황을 대비해야 하기 때문에 인터페이스를 둔다고 하는 것은 좀 실무랑 동떨어진 이야기일 수 있기도 하고
마지막으로 패턴 구현을 위한 코드 베이스가 더 커짐.. 물론 쿼리 코드가 서비스 레이어 안에 막 섞이는게 바람직한 현상은 아니기도 해서, 각각의 장점을 취하기 위한 적절한 고민은 필요할거같음
듣고보니 그러네
repository anti-pattern으로 검색하니까 진짜 c# 예제로 된 글들이 많이 나오네 ㅋㅋ
repository를 만들기 위한 과정이 좀만 더 복잡했어도 대부분의 팀에서 사용고려를 안했을거라 생각함. 지금은 프레임워크 코드 몇줄만 쓰면 뚝딱 완성이니까 쓴다고 생각.
오...
prisma 같은거 쓰면 그런 고민 안해도 된다 - dc App
놀랍게도 레포 패턴은 마소에서도 추천하는 방식이다. - dc App
닷넷쓰는데 항상 레포패턴만 써왔음. 그런사람들이 있는거지 다수설은 아님
링크좀. 나도 궁금하네