Udostępnij za pośrednictwem

Zabezpieczenia właściwości zależności

  • Artykuł

Właściwości zależności powinny być zwykle uważane za właściwości publiczne. Charakter systemu właściwości Windows Presentation Foundation (WPF) uniemożliwia udzielenie gwarancji bezpieczeństwa dotyczących wartości właściwości zależnej.

Dostęp i zabezpieczenia opakowań oraz właściwości zależności

Zazwyczaj właściwości zależności są implementowane wraz z właściwościami opakowania (wrappery) środowiska uruchomieniowego języka wspólnego (CLR), które upraszczają pobieranie lub ustawianie właściwości z wystąpienia. Jednak otoki są naprawdę tylko metodami ułatwiającymi, które służą do implementacji bazowych wywołań statycznych GetValue i SetValue używanych podczas interakcji z właściwościami związanymi z zależnościami. Myśląc o tym z innej perspektywy, właściwości są przedstawiane jako właściwości środowiska uruchomieniowego języka wspólnego (CLR), które przypadkowo są oparte na właściwościach zależności, a nie na polach prywatnych. Mechanizmy zabezpieczeń stosowane do opakowań nie odzwierciedlają działania systemu właściwości i dostępu do podstawowej właściwości zależności. Umieszczenie żądania zabezpieczeń na opakowaniu uniemożliwi użycie metody pomocniczej, ale nie uniemożliwi wywołań do GetValue lub SetValue. Podobnie umieszczenie chronionego lub prywatnego poziomu dostępu na opakowaniach nie gwarantuje skutecznych zabezpieczeń.

Jeśli piszesz własne właściwości zależności, należy zadeklarować opakowania i pole identyfikatora DependencyProperty jako publiczne elementy członkowskie, aby użytkownicy nie otrzymywali mylących informacji o prawdziwym poziomie dostępu tej właściwości (ze względu na implementację jej magazynu jako właściwości zależności).

W przypadku niestandardowej właściwości zależności można zarejestrować swoją właściwość jako właściwość zależności tylko do odczytu, co stanowi skuteczny sposób zapobiegania ustawianiu właściwości przez osoby, które nie posiadają odwołania do DependencyPropertyKey dla tej właściwości. Aby uzyskać więcej informacji, zobacz właściwości zależności Read-Only.

Notatka

Deklarowanie prywatnego pola identyfikatora DependencyProperty nie jest zabronione i może być używane do zmniejszenia natychmiast uwidocznionej przestrzeni nazw klasy niestandardowej, ale taka właściwość nie powinna być traktowana jako "prywatna" w tym samym sensie, co definicje języka wspólnego środowiska uruchomieniowego (CLR) definiują ten poziom dostępu, z powodów opisanych w następnej sekcji.

Ekspozycja systemu właściwości w kontekście właściwości zależnych

Nie jest to ogólnie przydatne i potencjalnie mylące, deklarowanie DependencyProperty jako poziomu dostępu innego niż publiczny. To ustawienie poziomu dostępu uniemożliwia tylko komuś uzyskanie odwołania do wystąpienia z klasy deklarującej. Istnieje jednak kilka aspektów systemu właściwości, które zwrócą wartość DependencyProperty w celu identyfikacji konkretnej właściwości, która istnieje w instancji klasy lub instancji klasy pochodnej, a ten identyfikator można nadal używać w wywołaniu SetValue, nawet jeśli oryginalny identyfikator statyczny jest zadeklarowany jako niepubliczny. Ponadto OnPropertyChanged metody wirtualne otrzymują informacje o dowolnej istniejącej właściwości zależności, która zmieniła wartość. Ponadto metoda GetLocalValueEnumerator zwraca identyfikatory dowolnej właściwości w wystąpieniach z lokalnie ustawioną wartością.

Walidacja i zabezpieczenia

Stosowanie żądania na ValidateValueCallback i oczekiwanie, że niepowodzenie walidacji przy niepowodzeniu żądania zapobiegnie ustawieniu właściwości, nie jest właściwym mechanizmem zabezpieczeń. Unieważnianie wartości ustawionej wymuszane przez ValidateValueCallback może być również pomijane przez złośliwych wywołujących, jeśli te wywołujące programy działają w domenie aplikacji.

Zobacz też