db 연결 방식

현업에서 db연결 시 wpf에서는 어떤 라이브러리를 사용하나요?
자바에서는 jpa를 사용해서 했던 것 같은데 wpf에서는 어떻게 사용하는 지 질문드립니다

2개의 좋아요

java의 jpa에 대응하는 .net ORM은 Entity FrameworkCore 입니다.

다만 java를 쓰실때 javafx나 swing 같은 데스크톱 프로그램을 만드실 때 ORM을 쓰시진 않으셨을 듯하고 Spring에서 쓰셨을 듯한데

아시겠지만 WPF는 Spring에 대응하는 기술은 아니고 aspnetcore가 대응하는 기술입니다. 따라서 데스크톱 어플리케이션인 WPF는 ef core를…굳이 사용하면 할 수는 있어도 사용하는 게 많지는 않은 듯 합니다.

.NET에서는 EF Core가 MS가 밀어주는 jpa와 같은 풀컨텍 ORM이고, 동등하게 유명한 StackOverFlow에서 만든 Dapper가 있습니다. Dapper는 mybatis 같은거라고 생각하시면 될것 같습니다.

5개의 좋아요

닷넷 진영에서 가장 간편하고 일반적인 접근 방식은 Entity Framework입니다. (WPF 기반 프로젝트에서도 많이 사용합니다.)

  • MSSQL, MySQL, PostgreSQL, SQLite 등 다양한 데이터베이스를 지원
  • LINQ 확장 메서드와 자연스럽게 통합되어 생산성이 뛰어남
  • Database First와 Code First 방식을 모두 지원

따라서 특별히 성능에 민감하거나 세밀한 튜닝이 필요한 상황이 아니라면, Entity Framework가 가장 우선적으로 고려할 만한 선택지입니다.

(그리고 질문글은 Q&A 게시판이 마련되어 있으니 적절한 카테고리에 올려주시기 바랍니다!:blush:)

5개의 좋아요

정정해서 말씀드리겠습니다.
Code-First라면 WPF에서 하는 게 적절하지 않은 듯하고(마이그레이션 히스토리에 대한 관리 때문) DB First라면 많이 있을 듯하네요. 저도 DB First로 사용했었습니다.

다만 제가 지금 하는 업무처럼 Column이 수시로 변하는 동적인 데이터를 다루는 경우라면 정적인 CS 코드로 정리되는 ORM이 아니라 따로 관리를 해야할 것 같습니다.

3개의 좋아요

추가적으로, 프로그래밍 관련 질문이기 때문에

WPF 관련 질문은 아니고 .NET에 관련된 질문 같아서 자유게시판에서 프로그래밍 언어 게시판으로 변경해드렸습니다.

3개의 좋아요

패키지 다운로드 횟수로 평가한다면, 닷넷에서 가장 많이 쓰이는 ORM 은 EF Core (17억 건)이고, 그 다음이 Dapper(5억 건)입니다.

보통은 SQL에 자신이 있다면, Dapper 를, 그렇지 않다면, EF Core 를 추천합니다만, 개인적으로 EF Core 를 추천합니다. (SQL에 자신이 있더라도)
왜냐하면, Dapper는 SQL을 문자열로 관리해야 해서, 안정성과 효율성 면에서 좋지 않기 때문입니다.

EF Core (와 같은 ORM)의 효용 가치가 크게 떨어지는 경우는, DB 담당자가 별도로 있고, 그 담당자가 쿼리문 전송 대신 저장 프로시져 호출을 우선 요구하는 경우 밖에 없을 것 같습니다. (이 부분에 대한 지원이 약합니다.)

EF Core 가 Full ORM인 이유는 (클래스) 코드로 DB를 설계(Code-First 전근법)하는 것과, DB로부터 코드를 생성하는 도구를 모두 제공하기 때문입니다.

특히 DB 설계할 때, 마이그레이션으로 DB의 형상을 관리하는 것은 거의 필수입니다. 이는 Git 으로 코드의 형상을 관리하는 것과 같습니다.

WPF 앱을 스탠드얼른 시스템(백엔드 없음)으로 설계하고, DB까지 설계해야 한다면, EF Core의 효용 가치는 극대화됩니다. 여기에 Sqlite를 선택한다면, 최상의 효율을 기대할 수 있습니다. 쿼리 통신 지연이 없기 때문입니다.

4개의 좋아요

dapper aid 추천 합니다.

2개의 좋아요

WPF든 WinForm이든 Asp.net 이든 EF (EntityFramework) 가 일단은 기본.
컬렉션을 다루는 Linq가 먼저 나오고 이후에 Linq 형식을 지원하는 Entity Framework가 나옴

장점

  1. Linq식으로 Collection이든 DB든 구분 없이 동일한 표현으로 사용 가능
  2. DB의 Relation을 코드 레벨에서 구분 없이 사용 가능
  3. DB 변경 시 Update 딸깍으로 반영 가능
  4. DB 변경 시 런타임이 아닌 컴파일 타임에서 오류 확인 가능
  5. 프로시저를 함수처럼 사용 가능 (단, 정석적인 프로시저로 만들었을 경우만 가능. 이럴 땐 이런 테이블 구조, 저럴 땐 저런 테이블 구조가 나오는 이상한 형식의 프로시저는 불가능)

단점

  1. DB의 데이터와 메모리의 데이터 구분을 잘 해야 됨
  2. 동일한 표현식이라도 DB의 데이터를 다둘때와 메모리의 데이터를 다룰때가 다름
  3. SQL 튜닝과 다르게 Linq 특유의 튜닝이 존재 함
  4. 점점 SQL을 까먹는 자신
2개의 좋아요