DbContext, DbSet 등등

c# dapper sql

문제

나는 dapper로 모든 데이터 접근을 구현하고있다. 나의 첫 번째 아이디어는 dapper를 사용하여 저장소 패턴을 구현하는 것이었다. from : http://www.bradoncode.com/blog/2012/12/creating-data-repository-using-dapper.html

그런 다음 예제 (동적 쿼리) 에서처럼 SQL을 최소화하기 위해 dapper sqlbuilder에 linq 표현식을 추가했습니다. 그래서 나는 다음과 같은 것을 쓸 수 있었다.

sqlbuilder.Where(c=>c.Id == 1) or c.Id = myVar

그리고 지금은 DbContext와 DbSet을 구현하고 linq 표현식을 사용하는 것이 좋은지 스스로에게 묻고 있습니다.

문제는 완전한 dbset 또는 dbcontext를 구현하는 것이 아닙니다. 그러나 (모든 복잡성없이) 보이는 단지.

DbContext는 연결을 초기화하고 여러 DbSet은 Dapper를 사용하여 테이블을 쿼리하고 iqueryable의 구현은 dapper sqlbuilder를 사용하여 지정된 링크 표현식을 기반으로 SQL을 "생성"합니다.

일부 코드를 읽고 엔티티 프레임 워크와 비교 한 후에 엔티티 프레임 워크가 이미 수행 했으므로 시간 낭비라고 생각합니다. 그러나 dapper를 사용하면 생성 된 sql의 전체 제어 권한을 가지며 항상 동일한 템플릿을 사용합니다.

시작하기 전에 (시간 낭비) 좋은 아이디어인지 아닌지 알고 싶습니다.

편집 : 많은 의견은 SqlBuider가 좋은 것이 아니라고 말합니다. 그렇다면 왜 Dapper 프로젝트에서 사용할 수 있습니까?

수락 된 답변

개인적으로 나는 그것이 dapper 라이브러리가 제공하려고 시도하는 것의 핵심 밖에있는 것이라고 말합니다. 이 아이디어에는 장점이 있지만, 그렇게 해봤을 때 yoouve는 기본적으로 LINQ-to-SQL을 다시 구현했습니다. 더 쉬운 방법은 LINQ-to-SQL을 사용하는 것 입니다. 그것이 우리합니다 (날씬한 저자) 그것을 사용하는 방법을 본질적으로 (그리고 그것을 계속 사용하는) 우리의 기존 L2S 코드베이스에 대해 - 단정은 일반적으로 L2S 모델을 채울 매우 행복하다. 그것은 또한 EF와 비슷할 것입니다.

그러나 실제로 작업을하고 싶다면이 작업을 수행 할 수있는 라이브러리를 작성할 수 있습니다. 이미 존재하는 일을하는 것은 많은 일처럼 보입니다.


인기 답변

Dapper의 핵심 기능은 성능입니다.

Dapper는 일반 SQL의 결과를 객체에 신속하게 매핑하기 위해 작성되었습니다. 그리고 확실히 개발자들이 SQL을 쓰는 것을 피할 수는 없습니다. SQL 빌더를 Dapper와 함께 사용하는 것은 좋지 않습니다. 더 나쁜 아이디어는 변경 추적을 구현하는 것입니다. 이러한 기능이 필요한 경우 엔티티 프레임 워크 나 다른 ORM을 사용하십시오.



아래 라이선스: CC-BY-SA with attribution
와 제휴하지 않음 Stack Overflow
아래 라이선스: CC-BY-SA with attribution
와 제휴하지 않음 Stack Overflow