언어와 상관없이, 데이터 베이스 연동은 크게,
- DB 클라이언트 구현 객체를 직접 이용하는 방법과,
- ORM을 이용하는 방법이 있습니다.
1번의 경우, 클라이언트에게 데이터 베이스 접속정보를 (커넥션 스트링을 통해) 전달해주고, 수동으로 접속을 하며, 데이터를 주고 받기 위해, 쿼리를 사용합니다.
그러면 클라이언트는 데이터베이스에 쿼리를 보내고 응답받은 결과를 코드에 넘겨줍니다.
이 방식이 가장 원시적인 - 좀 과격한 표현이네요 - 연동 방식이라고 생각하시면 됩니다.
닷넷에서는 Ado.Net 이 이 위치에 있습니다.
2 번 ORM의 경우, 프레임워크 세대 별로 추상화의 단계가 달라집니다.
닷넷의 예를 들면,
데이버 베이스 테이블을 테이블 객체로 변환 => DataTable class
쿼리를 사용합니다.
응답을 테이블 객체로 반환합니다.
테이블의 행과 열을 이용하여, 데이터에 접근합니다.
Part ORM => 대표적으로 Dapper
쿼리를 사용합니다.
응답에 포함된 레코드(한 행의 데이터)를 런타임 객체(보통 Entity 객체라고 합니다)로 맵핑해줍니다.
맵핑은 테이블의 필드와 클래스의 속성 사이의 연결을 가리킵니다.
users.id <=> User.Id
맵핑 표시방법은 속성에 어트리뷰트(닷넷에서는 어노테이션을 어트리뷰트라고 합니다)로 마킹하거나, 대충 눈치껏 알아서 해주기도 합니다.
Dapper 는 마이크로 ORM 이라고 불리기도 합니다. 작고 빠릅니다.
여기까지의 공통점은 코드에서 쿼리를 작성한다는 점인데, 이 방식의 단점은 쿼리도 알아야 하고, 소스코드에서 쿼리 관리가 쉽지 않다는 점입니다. 쿼리는 소스코드에서 문자열로 취급하는데, 리펙토링 도구를 사용하기에 한계가 있기 때문에, 수작업이 많이 필요할 수 있습니다.
Full ORM => Entity Framework (Core)
데이터 베이스 자체를 추상화합니다. 오로지 필요한 것은 접속정보입니다.
데이터 베이스에 관한 모든 작업 - 데이터베이스, 테이블 create/drop 포함 - 을 모두 코드에서 진행합니다. 즉 쿼리를 1도 안씁니다.
여전히 맵핑 정보를 제공해야 합니다.
Full ORM의 대표적인 장점으로는 데이터베이스 접속정보만 알고 있으면, 코드만으로 데이터 베이스 연동이 가능하다는 점입니다.
저도 한때는 Entity Framework 를 사용하려고 마음 먹었지만, 중급 이상이 레퍼런스를 찾기가 어려워서 여기 저기 물어봤습니다.
유튜브 RawCoding -
나 : 너 EF 강의하는데 너는 실무에 쓰냐?
RC: 안써.
나: 너도 안 쓰는 거 왜 강의하는데? EF는 교육용이냐?
RC : …
꽤 도움이 되는 조언은 유튜브 Sluiter 교수 채널에서 얻었습니다
EF 는 현업에서 선호되지 않는데, 그 이유는 실무에서는 DB의 관리는 프로그래머가 아닌, 전문 DBA 가 다루는 경우가 많기 때문.
Full ORM은 너무 많은 쿼리를 보내고, 프로그래머는 코드를 통해 비효율 쿼리를 너무 쉽게 보냄.
이는 DBA 업무의 방해 요소가 됨. DBA가 나름으로 날밤까며 최적화해놓은 DB의 성능이 수시로 무너지기 쉬움. DBA 가 정성스럽게 만들어 놓은 뷰 를 냅두고 여전히 Select 쿼리가 날라오는 등.
가장 근원적인 문제는 프로그래머가 ORM이 보내는 쿼리를 1도 볼 수 없다는 점이다. 즉, 프로그래머가 DBA의 불만을 수긍하여, 개선해보려고 해도, 프로그래머가 할 수 있는게 없음.
전문 DBA 까지 갖추지 못한 영세 사업장에서는 ORM이 개발 효율성을 높혀 주기도 하지만, 상업적 운용에는 비효율의 문제가 드러나고, 또한, ORM 자체에 대한 학습곡선이 결코 짧지 않다는 것도 큰 문제이다. 그걸 배울 시간이면, DB에 대한 중급 정도의 실력을 쌓을 수 있고, 그 정도면 프로그래머에게는 충분하다.