Dapper-dot-Net의 "Query"와 "QueryMultiple"은 하나의 결과 집합을 반환 할 때 성능과 동작이 동일합니까?

dapper

문제

우리는 최근 Dapper multimap func를 캡슐화하는 TableMapperT라는 매핑 클래스를 만들었습니다. 우리는 TableCommand라는 'command'객체와 별도로이 객체를 빌드합니다.이 객체는 SQL 텍스트 정보 등을 보유합니다. 그러나이를 사용하려면 단일 결과를 반환 한 다음 매핑하는 데 필요한 'QueryMultiple'을 사용해야합니다.

우리는 기본 성능 메트릭을 실행했으며 성능은 일반 Query api와 동일하게 나타납니다 (동일한 멀티 맵을 사용하는 동일한 쿼리를 반복하지만 'Read ()'를 사용하여 QueryMultiple을 사용함).

따라서 질문 하나, 단일 레코드 세트에 대해 QueryMultiple을 사용하는 경우 성능이나 동작에 근본적인 단점이 있습니까? 거기에는없는 것으로 보이지만, 큰 커뮤니티가 더 큰 통찰력을 가지고 있다고 생각합니다.

샘 사프란 (Sam Saffron)은 결과가이 게시물에 버퍼링되지 않았 음을 나타내지 만 ( Dapper.NET 및 여러 결과 세트가있는 proc에 저장되어 있음 ) 잠시 전에 나온 것이고 '버퍼링 됨'과 같은 소스 코드가 실제로 참 (public IEnumerable Read = true).

사용법 (아래)은 매우 깨끗하며 IDatabase 객체의 'Query'확장 메서드 인 연결 및 오류 처리를 한 곳에서 처리 할 수 ​​있습니다.

var command = new TableCommand(<SQL>,<Parameters>,<Timeout>);
var mapper = new TableMapper<OrderLineItem>();  //return type here
mapper.SetMap<OrderLineItem,Product>((oli,p)=>{oli.Product = p;return oli}); //input types here

return this.Database.Query(command,mapper);//returns IEnumerable<OrderLineItem>

수락 된 답변

여기서 문제는 성능이 아니라 편의입니다. 대부분의 쿼리 인 IMO는 단일 결과 그리드입니다. 여러 그리드 리더 시나리오의 추가 복잡성을 망쳐 놓지 않아도되는 것이 편리합니다. 각 그리드는 다른 모양이 될 수 있고 특정 순서로만 읽을 수 있기 때문에 필연적으로 더 복잡합니다.

버퍼링에 관해서 :

  • 전체 스트리밍을 위해 해제 할 수 있지만 기본적으로 그리드Read<T> / Query<T>
  • 그러나 멀티 그리드 API의 후속 그리드 는 요청시 에만 액세스 됩니다. 따라서 멀티 그리드 API를 차례로 사용해야합니다


아래 라이선스: CC-BY-SA with attribution
와 제휴하지 않음 Stack Overflow
이 KB는 합법적입니까? 예, 이유를 알아보십시오.
아래 라이선스: CC-BY-SA with attribution
와 제휴하지 않음 Stack Overflow
이 KB는 합법적입니까? 예, 이유를 알아보십시오.