C#에서 DB연동하는것에 대한 질문입니다.

안녕하세요, 회사 코드와 독학으로 C#을 공부하고 있습니다.
주로 ASP.NET과 WFP를 하고 있습니다.

그리고 스프링(자바)도 같이 다루고 있습니다.

스프링의 경우, MyBatis와 JPA를 사용하여 DB와 데이터를 주고 받는데
프로퍼티 파일에 접속 정보를 입력해두고, 어노테이션을 넣으면(몇가지 더 해야하지만) DB와 연동이 되는데요

저는 회사 코드를 중심으로 학습했는데…
회사 코드는 저렇게 설정파일+어노테이션으로 DB와 연동하는게 아니라

별도도 DB와 연동하기 위한 클래스 파일…대략 DBConn 같은 스태틱 클래스가 있고
그 클래스내에 상수로 DB 접속 정보를 적어두고

클래스를 호출하면서 쿼리를 같이 넘겨서 결과를 받는 방식으로 되어있습니다.

ef를 사용하는게 아니라면 대부분 저런 방식으로 하는건지
검색을 해봐도 비슷비슷하게 나오더라구요.

검색 요령이 안좋은건지, 문서를 봐도 비슷한 방식으로 진행하고…

위에 적어둔 스프링처럼, 어노테이션같은걸 활용하여 db에 접속하는 방식은 C#쪽에서 그다지 사용하지 않는 방식인건가요?

ef를 안(못) 쓸때엔 쿼리를 직접 적어서 사용하려는데… 마이바티스의 매퍼처럼 따로 저장해두는것도 거의 못 본거같고… (xml에서 가져오는건 구현할 줄 압니다)

자바쪽하고 C#쪽하고 그냥 주로 사용하는 방법이 다른건지 궁금합니다.

3개의 좋아요

데이터베이스 관련 질문이라 관련 카테고리로 변경 드렸습니다.

3개의 좋아요

유사하나 같지는 않습니다. 자바와 C#의 차이라기 보다는 라이브러리의 사용 방법의 차이라고 생각합니다.

.NET에서는 MyBatis와 유사한 Dapper라는 라이브러리가 있습니다. 어노테이션(C#에서는 특성)을 이용하는 방법은 없는 것 같지만 컴파일 시점에서 쿼리문을 검사해주지 않는 이상 일반 문자열로 쿼리를 표현하는것에 비해 특성이 어떤 장점이 있는지는 모르겠습니다.

아래의 링크를 통해 Dapper를 학습할 수 있습니다.

2개의 좋아요

안녕하세요. 김진석입니다.

JAVA에서 myBatis를 사용하셨으면 MyBatis.NET을 사용해 보시는 건 어떤가요?
개인적으로는 다양한 경험을 하는 건 좋지만 회사에서 쓰려면 다 배워야 하는 거라서 부담이 있을 수 있습니다.

쓰고 추천하는 것이 아니라 좀 그렇긴 한데 JAVA에서 해보셨으면 .net으로 왔다고 해서 뭐가 많이 다르진 않을 거에요.

아래 페이지를 참고해 보세요.

감사합니다.

3개의 좋아요

DB 를 다루는 고급 방법은 Entity Framre Work 로 Scaffolding 한뒤 linq로 Crud 하는 방법이 있습니다.
검색 Keyword : scaffolding c# entity framework
초급적인 방법은 : C# SqlConnection - C# 프로그래밍 배우기 (Learn C# Programming)
이런 방법이 있습니다.
java 에서 쓰던 xml binding 은 .net 있긴 하나 솔직히 거의 쓰지 않긴 해요 (ef 가 너무 편해서요)

3개의 좋아요

늦은 밤인데도 답변 감사합니다!

올려주신 방법으로 공부해보겠습니다(__)

3개의 좋아요

우리 회사도 그렇게 되어있습니다… DBConn(어째 이름도 같네요 ㅎㅎ;)클래스에… *.cs파일에 쿼리문 다 박아놓고 호출… 제가 알기론 이게 ADO.NET이라고 불리더라구요.
ORM 사용하지 않으면 이 외엔 데이터베이스 프로시저로 만들어놓던가…
제 대학 동기들이 다 개발자라 물어봤더니 거진 다 비슷비슷합니다.
물론 회사마다 다르겠지만 보통 빠른 생산성을 중요시한 곳은 이렇게 만드는 것 같네요.

3개의 좋아요
  1. EF VS JPA
    : JPA는 Repository 작성이 강제됨.
    : EF는 Repository 작성이 개발자에 맞겨짐. EF 자체가 Unit of Work 구현 이므로 Repository 작성이 불필요. 대신 직접 확장 클래스 또는 Linq를 통해 코드로 쿼리 작성.

  2. Dapper VS Mybatis
    : Dapper, Mybatis 둘 다 맵퍼 임.
    : Dapper는 Plain Text 또는 프로시저 Sql에 의존함.
    : Mybatis는 Mybatis sql xml 파일에 의존함.
    : 동적 쿼리 또는 조건별 쿼리 작성시 Dapper는 Sql에 의존하는 형태가 되고 Mybatis는 xml 구문에 의존하는 형태가 됨.

  3. 결론
    C# 기반 관련 DB 기술은 설정이나 사용법에 있어서 자유도가 높은 편입니다.
    JAVA - SPRING - 기반 DB 기술은 강력한 개발 방법론에 기인한 개발이므로 자유도가 없는 편입니다.

위와 같이 설명 드립니다.

4개의 좋아요

언어와 상관없이, 데이터 베이스 연동은 크게,

  1. DB 클라이언트 구현 객체를 직접 이용하는 방법과,
  2. 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에 대한 중급 정도의 실력을 쌓을 수 있고, 그 정도면 프로그래머에게는 충분하다.

3개의 좋아요