C# DB 라이브러리 비교

별로 구체적으로 비교를 해 본 것은 아니지만, 지난 두 달간 이런저런 삽질을 한 결과를 정리한다.

1. Linq To SQL - MS스러운 DB라이브러리
   1. 장점 - IDE에 통합된 사용환경, VS에서 DB에 연결 후, 테이블을 끌어오는 것만으로도 바로 도메인 객체가 생성된다. 속도가 빠르다. 복잡한 쿼리에 신경 안 써도 된다. 러닝커브 작음.
   2. 단점 - 자동생성되는 도메인 객체가 복잡하다. 로직이 들어가야 하는 경우 매우 곤란해진다. POCO객체는 불가능. 추가 수정도 귀찮다.
   3. 적절한 사용처 - 이미 DB가 존재하고, 거기에 간단한 CRUD연산을 해야 하는 웹 툴 정도를 붙이는 경우.
2. Entity Framework - Hibernate에 대응하는 ORM
   1. 장점 - 일단 코드를 짜고 바로 연결하면 된다. 복잡한 쿼리에 신경 안 써도 된다.
   2. 단점 - 라이브러리 사용법이 복잡하다. 제대로 쓰려면 책 한권 잡고 봐야 한다. 초기 러닝커브 크다. 속도가 느리다.
   3. 적절한 사용처 - 최초 프로젝트를 시작하고, 엔터프라이즈 환경… 인 경우… 하고 시간이 많고, 속도에 그리 신경쓰지 않아도 되고, 도메인 구조가 복잡하고 자주 변경되는 경우.
3. Dapper - MyBatis 류에 대응하는 ORM
   1. 장점 - 간단하다. 솔직히 SQL2LINQ보다 이게 더 간단해 보인다. 속도가 빠르다. 뭐 간단한 구조니까 당연하달까.
   2. 단점 - 쿼리를 직접 짜야 한다. 그러니 도메인 구조가 바뀌면 쿼리도 같이 바꿔줘야 하는 경우가 있다. 복잡한 매핑은 지원하지 않는다. 한 로우 마다 기본적으로 하나의 오브젝트에 대응하고, 대충 나눠서 여러 개를 매핑하는 것은 가능하지만, 조인해서 오브젝트 내부에 리스트를 넣는다든가 하는 것은 매핑 메소드를 따로 만들어줘야 한다.
   3. 적절한 사용처 - 속도가 중요하고, 초기 러닝커브가 크면 곤란한 경우. 개발자가 DB에 대해 좀 아는 경우.

• 개발 기간이 얼마 남지 않았다.
• 내가 DB를 설계할 수 있음.
• 도메인 구조가 자주 바뀐다.
• 도메인에 로직이 들어가야 하는 경우가 많다.
• 속도가 매우 중요.

1. 개발 기간이 얼마 남지 않았다.
   1. Entity프레임워크는 일단 제외 - 하이버네이트 때도 그랬지만, 러닝커브가 큰 라이브러리의 경우 개발시간 내내 익숙해지지 않는 경우가 많다.
2. 속도가 매우 중요.
   1. Enitity 프레임워크가 일단 또 제외.
3. 도메인에 로직이 들어가야 한다.
   1. SQL2LINQ가 제외.
4. 내가 DB를 설계할 수 있다.
   1. Dapper의 단점이 좀 경감