개발자
Nest.js에서 TypeOrm의 0.3버전에서는 @EntityRepository를 비활성화 시켰는데, 개발자분들께서는 이 이유에 대해 알고계시나요?
안녕하세요, 현재 NestJs를 공부하고 있는 취준생입니다. Typeorm의 0.2버전에서는 @Entityrepository를 제공해서, respository 레이어에 DB에 직접적으로 접근하는 코드(예: create, findOne 등)를 작성해왔었는데, 이번에 최신버전으로 업데이트되면서 해당 데코레이터를 비활성 시켰더라구요.. 그러다보니 Service 레이어에 임포트되는 라이브러리와 구현되는 로직이 더 길어지는 불편함이 있어 현재는 Custom Repository 방식을 사용하고 있습니다. 그러다 문득 TypeORM 측에서는 뭔가 이유가 있어 비활성화를 한 것 같은데.. Nestjs를 사용하고 계시는 개발자분들도 비슷하게 Cutsom Repository를 많이 사용하고 계신지, 아니면 service레이어에서 모두 해결하고 계신지 궁금합니다 예전에 레이어를 분리해서 사용했을 때는 예를 들어 "데이터를 조회하는 api을 구현하기 위해, repository레이어에서 findOne() 메서드만 실행시키고 그 값을 반환하는 A라는 함수를 정의하고 Service 레이어에서는 A함수를 불러와 바로 실행했을 때 결과는 동일하게 나왔던 경우"에는 굳이 새로운 메서드를 만들 필요가 있는가? 에 대해 의문을 가졌던 적은 있었는데, 소규모가 아닌 대규모 프로젝트에서도 별 차이가 없는건가요..?
답변 0
첫 답변을 기다리고 있어요.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2023년 12월 23일
@EntityRepository를 비활성화한 이유에 대해 TypeOrm 측에서는 명백히 언급하지 않았습니다. 그러나, 이 변경은 아마도 라이브러리가 더욱 일관성 있고 안정적으로 작동하도록 하기 위한 변경일 가능성이 큽니다. 특히 @EntityRepository를 사용한다면, 종종 TypeORM과 NestJS 간에 경계가 모호해지는 문제점이 있었습니다. 따라서 이로 인해 발생할 수 있는 버그를 방지하기 위해 해당 기능을 비활성화한 것으로 추정됩니다. 대부분의 개발자들은 Custom Repository를 사용하여 이 문제를 해결하고 있습니다. Custom Repository는 Repository를 조금 더 유연하게 확장할 수 있는 방법입니다. Service 레이어에서 직접 데이터베이스 로직을 처리하는 것보다 Repository 계층에서 데이터 접근을 처리하는 것이 코드 유지 관리및 재사용성 측면에서 보다 유리합니다. 소규모 프로젝트와 대규모 프로젝트 사이의 차이는 주로 복잡도와 관리에 있습니다. 대규모 프로젝트에서는 코드 베이스가 커지므로, 각각의 클래스와 함수가 담당하는 책임을 명확하게 구분하는 것이 유지 관리와 확장성을 위해 중요합니다. 따라서, 레포지토리 계층에 데이터베이스 접근 코드를 분리하여 Service 레이어가 비즈니스 로직에만 집중하도록 하는것은 대규모 프로젝트에서 특히 중요한 방법론입니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!