Dapper vs Entity Framework vs ADO.NET – 어떤 걸 써야 할까?
.NET에서 DB와 연결해서 데이터를 처리할 수 있는 방법은 여러 가지가 있다.
그중에서도 가장 많이 쓰는 세 가지는 다음과 같다.
- Entity Framework Core (ORM)
- Dapper (Micro ORM)
- ADO.NET
각 방식의 특징과 장단점, 그리고 언제 어떤 걸 선택해야 하는지 정리해봤다.
| 항목 | Entity Framework Core | Dapper | ADO.NET |
| 방식 | ORM (객체-관계 매핑) | Micro ORM | Low-level API |
| 접근 방식 | LINQ로 추상화된 쿼리 | 직접 SQL 작성 | SqlConnection, SqlCommand 직접 사용 |
| 코드량 | 적음 | 보통 | 많음 |
| 성능 | 중간 | 빠름 | 가장 빠름 |
| 유지보수 | 쉬움 | SQL 유지 필요 | 유지 난이도 높음 |
1. 코드 비교
//ADO.NET
using var conn = new SqlConnection(connectionString);
conn.Open();
var cmd = new SqlCommand("SELECT * FROM Users WHERE Id = @Id", conn);
cmd.Parameters.AddWithValue("@Id", 1);
using var reader = cmd.ExecuteReader();
while (reader.Read())
{
}
//Dapper
using var conn = new SqlConnection(connectionString);
var user = conn.QueryFirstOrDefault<User>("SELECT * FROM Users WHERE Id = @Id", new { Id = 1 });
//EF
var user = await _context.Users.FirstOrDefaultAsync(u => u.Id == 1);
2. 성능 비교
| 항목 | ADO.NET | Dapper | EF Core |
| 속도 | 🚀 최고속도 | 🔥 매우 빠름 | 😐 느림 |
| 메모리 사용량 | 낮음 | 중간 | 높음 |
| 처리량(TPS) | 높음 | 높음 | 낮음 |
| 추적 기능 | 없음 | 없음 | 있음(변경 감지) |
개인적인 선택
개인적으로 나는 거의 모든 프로젝트에서 Dapper를 기본으로 사용하고 있다.
쿼리를 직접 작성해야 하는 부담은 있지만,
SQL을 명확하게 통제할 수 있다는 점과 성능이 일정하게 나온다는 점이 큰 장점이다.
Entity Framework는 상황에 따라
물론 프로젝트 따라 Entity Framework를 사용하는 경우도 있다.
주로 다음과 같은 상황에서 EF를 선택하게 된다.
- 데이터 모델이 복잡하고 릴레이션이 많은 경우
- LINQ와 마이그레이션에 익숙한 경우
- 비즈니스 로직과 도메인 중심의 설계가 필요한 경우
다만 EF를 쓸 때도 항상 Db First 방식을 선호한다.
Code First 방식은 스키마 충돌이나 마이그레이션 충돌 문제가 자주 발생해서,
프로젝트 초기에만 편하지, 시간이 지날수록 유지보수에 더 부담이 된다.
Code First
Code First 방식은 개발 초기에는 확실히 편하다.
클래스만 정의하면 자동으로 테이블이 만들어지고, 마이그레이션도 바로 적용되기 때문에
스피드 있게 프로젝트를 시작할 수 있는 장점이 있다.
하지만 시간이 지나고 나면 문제가 생긴다.
- 팀원이 많아지고
- 마이그레이션 기록이 꼬이고
- DB를 수동으로 수정하거나 데이터 마이그레이션이 필요해지면
스키마 충돌이나 마이그레이션 에러가 자주 발생한다.
특히 CI/CD 환경에서 여러 개발자가 동시에 작업할 경우,
작은 변경이 전체 빌드나 배포에 영향을 주는 일이 많다.
물론 Code First로 시작하고 중간에 연결을 끊는 방식도 가능하긴 한데
초기에는 Code First로 개발하다가 어느 시점 이후부터는 Database First처럼 수동으로 DB를 관리하면서 모델만 유지하는 방식이다.
하지만 그렇게 되면 EF의 마이그레이션 기능을 더 이상 쓰지 못하게 되고,
결국 수작업으로 스키마를 관리해야 하므로 EF의 장점을 포기하는 셈이 된다.
외래키(Foreign Key) 설정은 가급적 피함
EF를 사용할 때는 외래키 설정은 제외하는 편이다.
왜냐하면
릴레이션이 걸려 있으면 데이터 수정이나 삭제 시 의도치 않은 제약이 발생할 수 있고
복잡한 모델일수록 이중, 삼중 참조가 꼬이면서 유지보수가 어려워지기 때문
대신 논리적으로만 참조 관계를 유지하고,
코드 레벨에서 필요한 검증만 수행하는 쪽으로 방향을 잡는다.
ADO.NET은?
ADO는 직접 쓰는 경우는 거의 없고,
기존에 만들어져 있는 오래된 코드 유지보수가 필요할 때
간단한 수정이나 리팩터링 정도만 하고 있다.
직접 객체 매핑을 다 해줘야 하고, 코드도 장황해서 가급적 피하고 싶은 스타일이다.
결론(개인적인 추천)
관리자 페이지 - Dapper + EF (혼합)
기능이 단순한 홈페이지 - EF Core
API 서버 - EF Core
MVP, 빠른 개발 - Dapper
마이그레이션 자동화 필요 - EF Core