GN⁺: ORM 여전히 안티 패턴인가요?
(github.com/getlago)- ORM (객체-관계 매퍼)은 소프트웨어 개발에서 반패턴으로 비판받는 경우가 많다.
- 그러나 이 비판은 과장된 것이며, ORMs는 다른 소프트웨어 도구와 마찬가지로 본질적으로 나쁘지 않다.
- ORM의 실제 문제는 종종 오용되거나 오해되는 경우가 많다.
- ORM과 관계형 데이터베이스는 다른 패러다임에서 작동하기 때문에 데이터 모델링과 관계에서 도전적인 문제가 발생할 수 있다.
- ORM은 단일 책임 원칙(SRP)과 관심사의 분리(SOC) 원칙을 위반하지만, 이러한 비판은 결코 결정적인 문제는 아니다.
- ORM의 실제 문제는 효율성과 가시성에 있다.
- 올바르게 사용되지 않으면 ORM은 비효율적일 수 있지만, 쿼리를 최적화하고 성능을 향상시킬 수 있는 기능을 갖추고 있다.
- ORM이 데이터베이스에 여러 번 왕복하는 N+1 문제는 데이터 로더를 사용하여 완화할 수 있다.
- ORM의 가장 큰 문제는 가시성과 디버깅이다. 명확한 오류 메시지를 제공하지 않거나 문제를 이해하고 해결하기 어렵게 만들 수 있다.
- 올바르게 사용될 때 ORM은 원시 SQL만큼 효율적일 수 있지만, 개발자는 기능과 네이티브 SQL 유사체를 활용해야 한다.
- 일부 복잡하거나 문제가 있는 쿼리의 경우, 원시 SQL 쿼리로 전환하는 것이 필요할 수 있다.
- 전반적으로, ORM은 본질적으로 나쁘지 않지만, 잠재적인 문제를 피하기 위해 신중하고 지식 있는 사용이 필요하다.
Hacker News 의견
- ORM의 한계와 단점, 예를 들어 다른 데이터베이스 사용 불가능성과 SQL 지식 요구 등이 비판받고 있다.
- 문자열 보간과 원시 JDBC에 가까운 방식으로 데이터 레이어를 하나의 쿼리씩 구축하는 것이 더 나은 접근법으로 여겨진다.
- ORM은 종종 기본 테이블 및 뷰 매핑에만 제한되어 SQL의 고급 기능과 능력을 무시한다.
- 두 가지 유형의 ORM이 있다: 도메인 모델을 기반으로 하는 것과 기존 데이터베이스에서 도메인 모델을 생성하는 것.
- jOOQ와 Hibernate와 같은 다양한 구현 및 기능을 가진 ORM은 각각 다른 목적으로 사용된다.
- ORM은 많은 테이블과 적절한 외래 키 관계를 가진 복잡한 애플리케이션에서 유용할 수 있다.
- 문자열 리터럴에서 원시 SQL을 사용하는 것은 ORM의 대안으로 간주되며, 쿼리 래퍼를 생성하는 도구도 사용할 수 있다.
- 모든 것을 번들로 숨기려 하지 않거나 자체 쿼리 언어를 도입하지 않는 실용적인 ORM이 선호된다.
- SQLAlchemy는 SQL을 재창조하지 않고 편리한 쿼리 레이어를 제공하는 접근법으로 칭찬받고 있다.
- ORM을 사용하지 않으면 개발자는 자체 데이터베이스 인터페이스를 작성하고 유지해야 하므로 버그와 보안 취약점이 발생할 수 있다.
- ORM이 SOLID 원칙을 어기는 것에 대한 비판은 학문적 가르침과 실제 개발 간의 충돌로 여겨진다.
- 경험이 부족하거나 학문적인 관행의 영향으로 인해 문제가 발생하고 예산 초과가 발생할 수 있다.