웹 파트 응용 프로그램에서 ASP.NET 서버 컨트롤 사용

아티클
10/22/2014

업데이트: 2007년 11월

웹 파트 응용 프로그램의 기본 UI(사용자 인터페이스)는 웹 페이지에서 공통 UI를 사용하고 WebPartZoneBase 클래스에서 파생되는 합성 컨트롤 형식을 통해 만들어지는 영역 내에 있는 ASP.NET 서버 컨트롤로 구성됩니다. 웹 파트 응용 프로그램의 기본 UI를 구성하는 이러한 서버 컨트롤의 기능은 기본 WebPart 클래스에 정의되지만 이 클래스에서 파생되는 컨트롤 외에 다른 컨트롤도 사용할 수 있습니다. 표준 ASP.NET 서버 컨트롤, 사용자 정의 컨트롤 또는 사용자 지정 서버 컨트롤을 사용할 수도 있습니다. 이 항목에서는 WebPart 클래스에서 상속되지 않은 서버 컨트롤을 웹 파트 응용 프로그램에서 사용하는 것과 관련된 몇 가지 문제를 설명합니다.

런타임 웹 파트 컨트롤 만들기

WebPart 클래스에서 상속되지 않은 다양한 유형의 서버 컨트롤에 대해 웹 파트 컨트롤 집합은 이러한 서버 컨트롤이 웹 파트 응용 프로그램에 참여하고 WebPart 클래스에서 파생되는 컨트롤과 같은 기능을 사용할 수 있게 하는 메커니즘을 제공합니다. 개발자는 이를 위해 특별한 작업을 수행할 필요가 없으며 서버 컨트롤을 WebPartZoneBase 영역에 추가하기만 하면 됩니다. 웹 페이지가 컴파일되면 영역에 포함되어 있지만 WebPart 클래스에서 상속되지 않은 서버 컨트롤이 GenericWebPart 클래스의 인스턴스로 자동 래핑되고 해당 인스턴스의 자식 컨트롤이 됩니다. GenericWebPart 클래스는 WebPart 클래스에서 상속되므로 이제 WebPart 컨트롤의 모든 기능이 포함된 서버 컨트롤을 사용할 수 있습니다. 실제로 WebPart 클래스에서 상속되지 않은 서버 컨트롤을 WebPartZoneBase 영역에 추가하면 개발자는 이 컨트롤이 런타임 WebPart 컨트롤이 되도록 설정합니다.

참고:
웹 파트 응용 프로그램에서 서버 컨트롤을 사용할 수 있듯이 웹 파트 응용 프로그램의 외부에서 WebPart 컨트롤을 사용할 수도 있습니다. WebPart 클래스에서 상속되는 컨트롤을 영역 외부에 추가하면 이 컨트롤은 일반적인 서버 컨트롤처럼 사용되고 웹 파트 기능이 없어집니다.

영역에 ASP.NET 서버 컨트롤 추가

ASP.NET 서버 컨트롤, 사용자 정의 컨트롤 또는 사용자 지정 컨트롤을 WebPartZoneBase 영역에 추가하는 경우 페이지에 특수한 기법이나 선언이 필요하지 않습니다. 일반적으로 웹 페이지에 컨트롤을 추가하는 것처럼 선언적으로(페이지 지속성 형식 사용) 또는 프로그래밍 방식으로 영역에 컨트롤을 추가할 수 있습니다. 또한 웹 파트 카탈로그 기능을 사용하면 사용자가 런타임에 컨트롤을 선택하여 페이지에 추가할 수 있는 카탈로그에 서버 컨트롤을 추가할 수 있습니다. 자세한 내용은 DeclarativeCatalogPart 및 ImportCatalogPart 컨트롤을 참조하십시오.

프로그래밍 방식으로 영역에 서버 컨트롤을 추가할 경우에는 WebPartManager 컨트롤의 AddWebPart 메서드를 사용하는 것이 좋습니다.

WebPart 컨트롤이 아닌 서버 컨트롤을 선언적으로 영역에 추가하는 경우 Microsoft Visual Studio 2005와 같은 비주얼 디자인 도구를 사용하면 속성 창 또는 IntelliSense에 WebPart 속성과 멤버가 나타나지 않습니다. 자세한 내용은 WebPart 컨트롤을 사용하는 경우와 다른 서버 컨트롤 사용을 비교하여 설명하는 다음 단원을 참조하십시오.

다양한 서버 컨트롤 옵션의 사용 시기 결정

웹 파트 응용 프로그램에서 모든 유형의 서버 컨트롤을 사용할 수 있으므로 WebPart 클래스에서 파생되는 컨트롤을 만들어야 하는 특별한 이유가 있는지 궁금할 수 있습니다.

그 판단을 위해서는 기존의 서버 컨트롤을 가져와 사용할 때의 이점과 WebPart 클래스에서 파생된 새 컨트롤을 만들 때의 이점을 비교하여 고려할 필요가 있습니다. 다음은 두 가지 방법 중 하나를 선택하려 할 때 결정에 도움이 되는 지침입니다.

서버 컨트롤 사용

컨트롤이 이미 있는 경우를 포함하여 대개는 ASP.NET 서버 컨트롤, 사용자 정의 컨트롤 또는 사용자 지정 컨트롤을 사용하도록 웹 파트 컨트롤을 만드는 것이 일반적입니다. 이러한 유형의 서버 컨트롤을 사용하면 런타임 웹 파트 기능을 모두 사용할 수 있으며 기존 코드를 다시 사용하고, 컨트롤 개발 정보를 활용하여 웹 파트 응용 프로그램에 적용하는 등 다양한 이점을 얻을 수 있습니다.

또한 WebPart 클래스에서 구현하는 몇 가지 인터페이스를 구현하여 실제 WebPart 컨트롤과 동일하게 동작하는 다양한 서버 컨트롤을 만들 수 있습니다. 예를 들면 다음과 같습니다.

IWebActionable 인터페이스. 이 인터페이스를 구현하면 컨트롤의 동사 메뉴에 사용자 지정 동사, 즉 사용자가 UI를 통해 컨트롤에 대해 수행할 수 있는 일반적인 작업(예: 최소화, 닫기 또는 편집)을 추가할 수 있습니다.
IWebEditable 인터페이스. 이 인터페이스를 구현하면 런타임에 사용자가 컨트롤의 사용자 지정 속성과 동작을 편집할 수 있도록 사용자 지정 EditorPart 컨트롤을 서버 컨트롤과 연결할 수 있습니다.
IWebPart 인터페이스. 이 인터페이스를 구현하면 Part 클래스에서 상속되는 실제 WebPart 컨트롤의 다양한 속성이 컨트롤에 포함되어 디자인 타임에서도 WebPart 컨트롤과 동일한 모양 및 느낌을 컨트롤에 제공할 수 있습니다.

WebPart에서 파생

WebPart 컨트롤에서 파생된 컨트롤을 만들면 웹 파트 관련 동작에 대한 모든 권한을 가질 수 있다는 주요한 이점이 있습니다.

컨트롤 개발자가 컨트롤의 런타임 동작을 변경한 다음 사용자에게 컨트롤을 다시 배포하려는 경우를 예로 들 수 있습니다. 개발자는 WebPart 클래스의 가상 속성 중 하나(예: AllowClose)를 재정의하여 항상 false를 반환하는 읽기 전용 속성으로 만들 수 있습니다. 이렇게 하면 컨트롤이 항상 열려 있게 되며 컨트롤 사용자는 이 동작을 변경할 수 없습니다.

디자인 타임 동작과 관련해서도 WebPart 클래스에서 상속하면 유용합니다. 페이지 개발자는 Microsoft Visual Studio 2005와 같은 비주얼 디자인 도구를 사용하는 경우 IntelliSense를 통해 디자인 타임에 WebPart 컨트롤에서 노출된 모든 WebPart 멤버를 볼 수 있으므로 선언 모드 및 속성 창에서 속성으로 작업할 수 있습니다. 이와 달리 디자인 타임에 영역에서 WebPart 컨트롤이 아닌 서버 컨트롤을 선언하면 IntelliSense 또는 속성 창에서 WebPart 클래스와 관련된 멤버를 선언할 수는 있지만 볼 수 없습니다. 일반적인 서버 컨트롤은 디자인 타임에 GenericWebPart 개체로 래핑되지 않은 상태이므로 런타임에 사용할 수 있는 WebPart 기능을 갖고 있지 않기 때문입니다. 위에 나열된 인터페이스를 구현하여 서버 컨트롤의 모양과 동작을 WebPart 컨트롤과 동일하게 만들 수 있지만 WebPart 컨트롤을 직접 만드는 것이 더 간단한 경우가 많습니다. 컨트롤 패키지를 만드는 컨트롤 개발자와 공급업체는 WebPart 클래스에서 컨트롤을 파생시키는 방법으로 다양한 디자인 타임 기능을 컨트롤에 제공할 수 있습니다.

결론

결론적으로 컨트롤의 표준 속성을 재정의할 필요가 없다면 기존의 서버 컨트롤을 사용하여 이를 WebPart 컨트롤의 일부로 만드는 것이 더 쉽습니다.

사용자 지정 WebPart 컨트롤을 만들려는 경우에는 다음과 같은 속성을 재정의할 수 있습니다.

사용자 정의 컨트롤을 WebPart 컨트롤로 사용

사용자 정의 컨트롤을 사용하면 웹 페이지에 사용되는 것과 동일한 선언 구문을 사용하여 컨트롤의 복잡한 UI를 신속하게 빌드할 수 있으므로 ASP.NET 개발자에게 사용자 정의 컨트롤은 매우 유용한 옵션입니다. 또한 사용자 정의 컨트롤을 사용하면 매우 편리하게 여러 페이지에서 코드를 분할하고 다시 사용할 수도 있습니다. ASP.NET 서버 컨트롤과 마찬가지로 사용자 정의 컨트롤도 웹 파트 응용 프로그램에 사용하면 유용합니다. 사용자 정의 컨트롤은 WebPartZoneBase 영역에 직접 추가될 수 있으며 위에서 설명한 대로 런타임 WebPart 컨트롤로 사용됩니다. 또한 사용자 정의 컨트롤은 웹 파트 카탈로그 기능에도 사용됩니다. 이때 가져올 수 있는 컨트롤로 사용되거나, 사용자가 선택하여 페이지에 추가할 수 있는 다른 서버 컨트롤 집합을 패키지하는 데 사용됩니다. 자세한 내용은 WebPartsListUserControlPath 속성을 참조하십시오.

중요:
런타임 WebPart 컨트롤로 사용되는 사용자 정의 컨트롤에서는 ASP.NET 출력 캐싱을 사용할 수 없음을 알고 있어야 합니다. 웹 파트 컨트롤 집합의 경우 각 페이지 요청에 대해 컨트롤이 컨트롤 트리에 있어야 합니다. 개인 설정(자세한 내용은 웹 파트 개인 설정 개요 참조) 같은 특정 웹 파트 기능을 사용하려면 이 조건이 충족되어야 합니다. 사용자 정의 컨트롤이 캐시되는 요청의 경우(자세한 내용은 @ OutputCache 지시문 참조) 컨트롤 트리에 컨트롤이 추가되지 않습니다. 따라서 출력 캐싱은 웹 파트 기능과 호환되지 않으며 웹 파트 응용 프로그램에서 WebPart 컨트롤로 사용되는 사용자 정의 컨트롤에서 동작하지 않습니다.

런타임 WebPart 컨트롤로 사용되는 사용자 정의 컨트롤에서는 ASP.NET 출력 캐싱을 사용할 수 없음을 알고 있어야 합니다. 웹 파트 컨트롤 집합의 경우 각 페이지 요청에 대해 컨트롤이 컨트롤 트리에 있어야 합니다. 개인 설정(자세한 내용은 웹 파트 개인 설정 개요 참조) 같은 특정 웹 파트 기능을 사용하려면 이 조건이 충족되어야 합니다. 사용자 정의 컨트롤이 캐시되는 요청의 경우(자세한 내용은 @ OutputCache 지시문 참조) 컨트롤 트리에 컨트롤이 추가되지 않습니다. 따라서 출력 캐싱은 웹 파트 기능과 호환되지 않으며 웹 파트 응용 프로그램에서 WebPart 컨트롤로 사용되는 사용자 정의 컨트롤에서 동작하지 않습니다.