더 빈번하게 작은 전화를해야합니까? 또는 덜 자주 전화를 자주?

Question

질문은 일종의로드 된 것 같지만 약간의 피드백을 원했습니다. 현재 dtos를 통해 웹 서비스에서 poco 클래스 객체를 생성하고 있습니다. 모든 스칼라 값을 미리로드하고 모든 바이너리를 포함하는 모든 콜렉션/배열을 게으른로드합니다.

분명히이 라이브러리는 웹 애플리케이션을 구동하기 때문에 응답 시간을 향상시키기 위해이 작업을 수행했습니다. 하지만 서비스를 재사용 할 수 있도록 각 GET 함수를 단일 액션 (S)으로 정규화했습니다. 예를 들어, 활성 디렉토리에서 사용자 정보를 가져 오는 것은 하나의 예 (예 : displayName 및 department와 같은 스칼라 값)이며,이 사람의 직접 보고서를 가져 오는 것은 별도의 지연로드 된 작업입니다. 그래서 어떻게 될까요, 당신이 객체를 만들 때,이 객체를 빌드하는 서비스에 대한 수많은 호출이 있습니다. 일부 페이지는 기본 정보 만 필요하고 다른 페이지는 게으른로드 메소드 또는 전체 객체를 더 많이 호출합니다. 나는 이것에 문제가 보이지 않지만 내가 궁금해하는 것은 (그리고 다른 사람들은 이미 비판하고있다) 이것이 문제가 될 것인지 아닌가?

내 질문에 내가 잘못하고 있니? 모든 입력은 감사하지만. 감사합니다

Answer 1

큰 요청이나 응답을 전송하는 오버 헤드와 비교할 때 공격해야 할 균형은 HTTP 호출의 오버 헤드입니다.

은색 총알이 없습니다. 예를 들어 LAN을 통해 한 서버에서 다른 서버로 전화가 걸려 오면 큰 페이로드는별로 문제가되지 않습니다. 모바일 장치에서 전화가 걸려 오면 페이로드를 다듬는 것이 많은 이점을 얻을 수 있습니다.

가장 좋은 균형은 웹 서비스의 방법을 워크 플로의 단계로 보는 것입니다. "X를 얻고 싶다면 어떤 데이터가 필요합니까?" 그러한 생각을 중심으로 요청 응답 범위를 파악한 다음 결과를 분석하십시오. 이것은 단지 출발점 일 뿐이지 만, "모든 세부 사항에 대해 하나의 방법"또는 모든 것을 허용하는 하나의 방법으로 시작하는 것보다 낫습니다.

Answer 2

나는 이것에 문제가 보이지 않지만 내가 궁금해하는 점은 (그리고 다른 사람들은 이미 비판하고있다.) 이것은 문제가 될 것인가?

문제는 각 서비스 호출이 오버 헤드를 제공한다는 것입니다. 더 적은 수의 큰 호출로 더 나은 총 처리량을 얻을 수 있습니다.

여기에는 항상 균형이 잡혀 있고 균형점이 있습니다. 통화가 많을수록 필요한 것보다 더 많은 데이터를 가져올 위험이 따르므로 리소스도 낭비됩니다.

Answer 3

큰 투표 횟수가 적은 투표에 투표합니다.

웹 컨텍스트에 있기 때문에 데이터 저장소에서 응용 프로그램 계층으로 이동 한 다음 웹 계층으로 이동하는 데 비용이 많이 드는 작업이므로 네트워크 통과가 가장 많은 리소스를 차지합니다. 따라서 웹 계층의 캐싱 메커니즘을 통한 호출 빈도가 줄어들고 개인적인 경험에서 비롯됩니다.

또한 '큰'으로 정의하는 것은 응용 프로그램 사용법에 따라 다릅니다. 예 : 대부분의 사용자가 기본 정보 만보고 일부만 직접 보고서로 넘어가는 경우 두 번의 개별 통화를 사용할 수 있습니다. 그렇지 않으면 하나 붙어.

희망이 도움이됩니다.