다음과 같은 시나리오를위한 가장 좋은 방법 일 것입니다 무엇 :모범 사례
잠깐만 실례 각 행에 따라 작성되고 변경해야합니다 그리드를. 예를 들어, 제품으로 채워진 그리드가 있고 각 제품에 따라 열 중 하나가 동적으로 채워집니다. 모든 productdetail 테이블에서 서비스를 반환하고 클라이언트 측에서 쿼리하는 것이 더 좋습니까? 아니면 필요한 데이터 만 반환하는 서비스 메서드가 있습니까? 후자는 그리드에 n 개의 제품이있는 경우 해당 서비스 메소드에 대한 n 개의 요청이 있음을 의미합니다.
일부 딜레마는 테이블이 상대적으로 작고 클라이언트에게 보내는 것이 그리 중요하지 않지만 다른 사용자에게는 반환되는 행이 상당합니다 (15k 이상).
당신이 가져올 수있는 통찰력에 감사드립니다.
클라이언트의 데이터를 맞추기 위해 서버에 ViewModel을 만드는 것이 좋습니다. 이는 두 번째 옵션과 유사합니다. 그러나 행별로 행해지지는 않습니다. 뷰가 특별한 논리를 필요로하지 않도록 열을 준비하는 것은 서버 측의 일괄 작업입니다.
브라우저, OS, 컴퓨팅 성능이 매우 다양하기 때문에 클라이언트 측에서의 데이터 조작이 까다로울 수 있습니다. 서버를 제어하므로 가능한 한 많이 제어 할 수 있습니다.
행운을 빈다.
서비스에서 일종의 페이징을 구현하도록하고 클라이언트가 원하는 레코드 수 (일반적으로 시작 인덱스와 개수 또는 그와 비슷한 것)를 요청할 수있게 할 수 있습니다. 거대한 요청을 처리 할 필요가 없도록 특정 크기로 페이지 크기를 제한 할 수 있습니다.
이렇게 사용하면 각 요청에서 제공되는 데이터의 크기와 수행되는 호출의 수간에 좋은 균형을 찾을 수 있습니다.
여기서 네트워크 대기 시간과 같은 소리가 문제입니다. 100 개의 제품과 왕복 시간이 0.2 초라면 모든 데이터를로드하는 데 20 초가 걸립니다. 가능한 한 서비스 호출을 최소화하고 필요한 경우 클라이언트의보다 적합한 구조로 데이터를 다시 매핑하십시오.
편집 : 상황에 따라 가능한 경우 다른 아이디어는 클라이언트와 서비스간에 데이터를 압축하는 것입니다. this forum post을보십시오. XML 힙 (heap of XML)을 추진한다면 큰 이득을 볼 수 있습니다.
당신이 우연히 만난 주제는 granularity의 주제를 따뜻하게 토론 한 것입니다. service-oriented architecture입니다. SOA는 mystic mammal being discussed by blind men과 같지만 실제로는 그렇지 않습니다.
트렌드의 "best practice"은 개체 지향적 인 출발이라는 거친 서비스입니다. 귀하의 서비스가 문서를 교환하는 것으로 생각하십시오. 문서를 교환하면 필요한 일을 처리하는 데 필요한 모든 것을 넣을 수 있습니다.
Andy White가 제안한 것처럼 데이터가 너무 커지면 필터링이나 페이징이 필요합니다.