이전에 프로토타입으로 작성한 프로젝트를 모놀리스에서 MSA로 리팩터링 하려고 했습니다. 이를 위해 ORM을 비교하던 중 Dapper와 EF를 두고 고민했는데 고려한 내용을 정리해 둡니다.
주요 차이점.
가장 큰 비교 요인으로 꼽히는 것은 성능입니다. Dapper는 EF에 비해 많은 기능을 희생했지만 그만큼 더 빠르다고 알려져 있습니다. 반대로 EF는 성능을 희생시키고 Dapper에서 지원하지 않는 어려운 기능들을 수행해 냅니다.
EF를 채택하는 주요한 기능은 Linq입니다. Linq로 인해 런타임에 SQL로 변환됩니다. EF의 Linq 지원은 실제로 IMO 채택을 주도한 주요한 요인입니다.
Dapper는 간단하면서 강력합니다. 그야말로 Simple is fast를 추구하는 것 같았습니다. EF에 비하면 초라한 기능이지만 성능면에서는 뛰어납니다.
반면에 EF는 Linq를 지원하고 변경 감지 기능이 있어 dbContext.SaveChanges()를 통해 모든 업데이트를 한 번에 처리할 수 있습니다. 상속도 내장되어 있고 분할 쿼리, 전역 쿼리 필터, 전체 트랜잭션 관리, 마이그레이션 등 수많은 기능을 포함하고 있습니다.
Dapper는 개발 시 개발자가 raw 쿼리를 직접 작성해야 합니다. 이는 단점으로 보일 수 있지만 장점으로 작용할 수 도 있습니다.
EF의 성능 개선.
MS에 따르면 EF 7에서 데이터베이스에 대한 왕복 횟수를 줄이고 보다 효율적인 SQL을 생성하도록 변경되어 SaveChanges와 SaveChangesAsync의 성능이 일부 시나리오에서 EF 6에 비해 4배 빨라졌다고 게시하였습니다.
EF 6.0의 글에선 EF 6의 성능은 업계 표준 TechEmpower Fortunes 벤치마크에서 5.0에 비해 70% 더 빠르다고 게시한 바 있으며 벤치마크 코드, dotNET 런타임 등의 개선을 포함하여 전체 성능이 개선되어 EF Core 6.0 자체는 쿼리 실행 속도가 31% 더 빨라졌다고 게시한 바 있습니다.
이렇듯 EF는 기존에 Dapper에 비해 성능이 좋지 않아 지속적으로 성능을 개선시켜 나아가고 있습니다. 추후에는 더 나은 성능 개선을 바랄 수 있을 것으로 생각됩니다.
Dapper의 추가 라이브러리.
Dapper는 성능을 위해 많은 기능을 희생했습니다. 하지만 그렇다고 희생한 기능을 사용하지 못하는 것은 아닙니다. Dapper는 새로운 기능을 제공하는 확장 라이브러리가 있습니다.
이러한 라이브러리들은 Dapper에서 기본적으로 제공하지 않는 기능을 지원해 유용하게 사용할 수 있으나 다른 라이브러리를 사용하면 Dapper에서 제공한 성능 벤치마크의 결과가 바뀔 수 있음을 유념해야 합니다.
결론.
다양한 레퍼런스를 찾아본 결과 결국 EF 7을 사용하기로 결정했습니다.
공식적으로 MS에서는 EF를 지원하는 것도 한몫했습니다. EF는 앞으로도 dotNet 버전과 함께 개선될게 분명하며 시간이 지나 신규 버전이 나올수록 개선되는 성능과 최신 벤치마크 테스트 결과 눈에 띄게 차이 나지 않는 성능으로 인해 딱히 Dapper를 사용해야 할 필요성을 느끼지 못했습니다.
