C \ # 디자인 모드 의 프 록 시 모드 (3)

15.4 원 격 에이전트
      원 격 프 록 시 (Remote Proxy) 는 클 라 이언 트 프로그램 이 원 격 호스트 에 있 는 대상 에 접근 할 수 있 도록 자주 사용 하 는 프 록 시 모드 입 니 다. 원 격 호스트 는 더 좋 은 계산 성능 과 처리 속 도 를 가지 고 클 라 이언 트 의 요청 에 신속하게 응답 하고 처리 할 수 있 습 니 다.원 격 에이 전 트 는 네트워크 의 세부 사항 을 숨 길 수 있어 서 클 라 이언 트 가 네트워크 의 존 재 를 고려 할 필요 가 없다.클 라 이언 트 는 에이전트 의 원 격 업무 대상 이 원 격 이 아니 라 로 컬 에 있다 고 볼 수 있 고 원 격 에이전트 대상 은 대부분의 네트워크 통신 업 무 를 맡 았 으 며 원 격 업무 방법 에 대한 호출 을 맡 았 다.
       원 격 프 록 시 설명도 그림 15 - 5 에서 보 듯 이 클 라 이언 트 대상 은 원 격 호스트 의 업무 대상 을 직접 방문 할 수 없고 간접 적 으로 방문 하 는 방식 만 취 할 수 있다.원 격 업무 대상 은 로 컬 호스트 에 프 록 시 대상 이 있 습 니 다. 이 프 록 시 대상 은 원 격 업무 대상 에 대한 접근 과 네트워크 통신 을 담당 합 니 다. 클 라 이언 트 대상 에 게 는 투명 합 니 다.클 라 이언 트 는 구체 적 인 업 무 를 실현 하 는 사람 이 누구 인지 관심 을 가 질 필요 가 없다. 서비스 인터페이스 가 정의 하 는 방식 에 따라 로 컬 호스트 의 대리 대상 과 직접 상호작용 을 하면 된다.
그림 15 - 5 원 격 에이전트 설명도
      . NET 플랫폼 을 기반 으로 하 는 분포 식 기술, 예 를 들 어 DCOM (Distribute Component Object Model, 분포 식 구성 요소 대상 모델), Web Service 에서 모두 원 격 에이전트 모델 을 응용 하여 관련 자 료 를 조회 하여 확장 학습 을 할 수 있 습 니 다.
 
15.5 가상 에이전트
       가상 에이전트 (Virtual Proxy) 도 자주 사용 하 는 에이전트 모델 로 시스템 자원 을 많이 차지 하거나 불 러 오 는 시간 이 긴 대상 에 게 가상 대 리 를 제공 할 수 있다.실제 대상 이 만 들 기 전에 가상 대 리 는 실제 대상 의 대역 을 맡 고 실제 대상 이 만 든 후에 가상 대 리 는 사용자 의 요 구 를 실제 대상 에 게 전달 합 니 다.
       일반적으로 다음 과 같은 두 가지 상황 에서 가상 대 리 를 사용 하 는 것 을 고려 할 수 있다.
        (1) 대상 자체 의 복잡성 이나 네트워크 등 으로 인해 한 대상 은 비교적 긴 로드 시간 이 필요 하 다. 이때 로드 시간 이 상대 적 으로 짧 은 대리 대상 으로 실제 대상 을 대표 할 수 있다.일반적으로 실현 할 때 다 중 스 레 드 기술 과 결합 할 수 있 습 니 다. 하나의 스 레 드 는 프 록 시 대상 을 표시 하 는 데 사용 되 고 다른 스 레 드 는 실제 대상 을 불 러 오 는 데 사 용 됩 니 다.이러한 가상 프 록 시 모드 는 프로그램 이 시 작 될 때 사용 할 수 있 습 니 다. 프 록 시 대상 을 만 드 는 것 은 시간 과 처리 복잡 도가 실제 대상 을 만 드 는 것 보다 적 기 때문에 프로그램 이 시 작 될 때 실제 대상 대신 프 록 시 대상 으로 초기 화 할 수 있 고 시스템 의 시작 시간 을 크게 가속 화 할 수 있 습 니 다.실제 대상 을 사용 해 야 할 때 프 록 시 대상 을 통 해 참조 합 니 다. 이때 실제 대상 은 로드 에 성공 하여 사용자 의 대기 시간 을 단축 시 킬 수 있 습 니 다.
      (2) 한 대상 의 로드 가 시스템 자원 을 많이 소모 할 때 가상 대 리 를 사용 하기에 도 매우 적합 하 다.가상 에이 전 트 는 대량의 메모 리 를 차지 하거나 처리 하기 매우 복잡 한 대상 을 사용 할 때 만 들 수 있 습 니 다. 그 전에 상대 적 으로 자원 을 적 게 차지 하 는 에이전트 대상 으로 실제 대상 을 대표 하고 에이전트 대상 을 통 해 진실 한 이미 지 를 참조 할 수 있 습 니 다.메모 리 를 절약 하기 위해 서 는 실제 대상 을 처음 인용 할 때 대상 을 만 들 고 이 대상 을 여러 번 재 활용 할 수 있 습 니 다. 나중에 방문 할 때마다 필요 한 대상 이 만 들 어 졌 는 지 확인 해 야 합 니 다. 따라서 이 대상 을 방문 할 때 존재 성 검 사 를 해 야 합 니 다. 시스템 시간 이 필요 하지만 메모리 공간 을 절약 할 수 있 습 니 다.이것 은 시간 으로 공간 을 바 꾸 는 방법 이다.
       이상 의 어떤 상황 이 든 가상 대 리 는 '허위' 의 대리 대상 으로 진실 대상 을 대표 하고 대리 대상 을 통 해 진실 대상 을 간접 적 으로 인용 하여 어느 정도 시스템 의 성능 을 향상 시 킬 수 있다.
 
15.6 버퍼 에이전트
       버퍼 에이전트 (Cache Proxy) 도 비교적 자주 사용 하 는 프 록 시 모드 로 특정한 작업 결과 에 임시 캐 시 저장 공간 을 제공 하여 후속 사용 에서 이러한 결 과 를 공유 할 수 있 도록 일부 방법의 중복 실행 을 피하 고 시스템 성능 을 최적화 할 수 있 습 니 다.
       마이크로소프트 예제 프로젝트 PetShop 4.0 의 비 즈 니스 논리 층 (Business Logic Layer, BLL) 에 서 는 Product, Category, Item 등 을 정의 하 였 으 며, 데이터 액세스 층 (Data Access Layer, DAL) 대상 을 호출 하여 데이터 베 이 스 를 방문 하여 관련 데 이 터 를 얻 을 수 있 도록 관련 업무 방법 을 패키지 하 였 다.시스템 성능 을 개선 하기 위해 PetShop 4.0 은 이러한 실현 방법 에 캐 시 체 제 를 추가 하고 새로운 대상 을 도입 하여 원래 의 BLL 업무 논리 대상 을 제어 합 니 다. 이 새로운 대상 들 은 프 록 시 모드 의 프 록 시 대상 에 대응 합 니 다.프 록 시 모드 를 도입 한 후 캐 시 단계 에서 업무 대상 에 대한 패 키 징 을 실현 하여 업무 대상 에 대한 통 제 를 강화 하 였 으 며, 방문 해 야 할 데이터 가 캐 시 에 이미 존재 한다 면 데 이 터 를 가 져 오 는 방법 을 반복 하지 않 고 캐 시 에 저 장 된 수 거 를 되 돌려 주면 됩 니 다.기 존의 업무 대상 (실제 대상) 과 새로 추 가 된 대리 대상 이 외부 에 노출 되 는 방법 이 일치 하기 때문에 호출 자 즉 클 라 이언 트 에 게 호출 대리 대상 과 실제 대상 은 실질 적 인 차이 가 없다.
       새로 도 입 된 프 록 시 클래스 는 ProductDataProxy, CategoryDataProxy, ItemDataProxy 등 을 포함한다.다음은 PetShop. BLL. Product 업무 대상 을 예 로 들 어 설명 한다. PetShop 4.0 은 대리 대상 인 ProductDataProxy 를 구축 하고 ProductDataProxy 의 GetProductsByCategory () 방법 에서 업무 논리 층 인 Product 류 의 GetProductsByCategory () 방법 을 호출 하 며 캐 시 메커니즘 을 추가 했다.그림 15 - 6 참조:
그림 15 - 6 PetShop 4.0 캐 시 에이전트 설명도
       ProductDataProxy 클래스 에 다음 코드 세 션 이 존재 합 니 다.

public static class ProductDataProxy
{
    private static readonly int productTimeout = int.Parse(ConfigurationManager.AppSettings ["ProductCacheDuration"]);
    private static readonly bool enableCaching = bool.Parse(ConfigurationManager. AppSettings["EnableCaching"]); 

    public static IList GetProductsByCategory(string category)
    {        
        Product product = new Product();

        //       ，     product       
         if (!enableCaching)
        {
            return product.GetProductsByCategory(category);
        }

        string key = "product_by_category_" + category;
        //        
         IList data = (IList )HttpRuntime.Cache[key];  

        //                
          if (data == null)
        {            
          data = product.GetProductsByCategory(category);            
          //      AggregateCacheDependency  
            AggregateCacheDependency cd = DependencyFacade.GetProductDependency (); 
          //         ，      AggregateCacheDependency  
            HttpRuntime.Cache.Add(key, data, cd, DateTime.Now.AddHours(product Timeout), Cache.NoSlidingExpiration, CacheItemPriority.High, null); 
        }
        return data;
    }
        ……
}

       상기 코드 에서 AggregateCacheDependency 는. NET Framework 2.0 부터 추 가 된 클래스 로 의존 항목 대상 의 집합 을 감시 합 니 다.이 집합 에 있 는 임의의 의존 대상 이 바 뀌 면 이 의존 대상 에 대응 하 는 캐 시 대상 은 자동 으로 삭 제 됩 니 다.이 는 AggregateCheDependency 에 대한 상세 한 설명 이 아 닙 니 다. 관련 자 료 를 찾 아 보고 확장 학습 을 할 수 있 습 니 다.
       비 즈 니스 논리 층 제품 대상 의 GetProducts ByCategory () 방법 에 비해 상기 코드 는 캐 시 메커니즘 을 증가 시 켰 다.캐 시 에 관련 데이터 항목 이 존재 하지 않 을 경우 비 즈 니스 논리 층 Product 의 GetProducts ByCategory () 방법 을 직접 호출 하여 데 이 터 를 가 져 오고 해당 하 는 AggregateCacheDependency 대상 과 함께 캐 시 에 저장 합 니 다.ProductDataProxy 류 의 모든 업무 방법 에서 제품 류 를 예화 하고 제품 류 의 해당 방법 을 호출 하기 때문에 ProductDataProxy 와 제품 간 은 의존 관계 에 속한다. 이것 은 표준 대리 모델 의 변형 으로 표준 대리 모델 에 따라 개선 할 수 있다. 이 는 고 층 의 추상 적 인 인 인 터 페 이 스 를 도입 하 는 것 을 포함한다.
[저자: 류 웨 이 (써 니)  http://blog.csdn.net/lovelion】