2013-10-31 8 views
6

Ich versuche einige verschiedene Dinge mit MVVM. In unserem ViewModel sind Eigenschaften, die an View gebunden sind, öffentlich. Ich nehme ein Beispiel für eine Knopfbindung. Hier ist ein einfaches Beispiel.Binding-Eigenschaft intern statt öffentlich in ViewModel machen

View.xaml:

<Button Content="Test Button" Command="{Binding TestButtonCommand}" /> 

ViewModel.cs

private ICommand _testButtonCommand; 
public ICommand TestButtonCommand 
{ 
    get { return _testButtonCommand?? (_testButtonCommand= new RelayCommand(SomeMethod)); } 
} 

Hier meine Frage ist, dass wir TestButtonCommand intern statt öffentlich machen? Intern bedeutet, dass es für das aktuelle Projekt zugänglich ist, also sollte es kein Problem sein, das zu tun? Aber als ich das versuchte, hat es nicht funktioniert. Das Hinzufügen eines Haltepunkts in Getter wurde nicht getroffen. Warum können wir es nicht intern machen?

Hier ist der Link von msdn.

http://msdn.microsoft.com/en-us/library/ms743643.aspx

Die Eigenschaften verwenden Sie als Bindungsquelle Eigenschaften für eine Bindung müssen die öffentlichen Eigenschaften der Klasse sein. Auf explizit definierte Schnittstelleneigenschaften kann für Bindungszwecke nicht zugegriffen werden, und auch keine geschützten, privaten, internen oder virtuellen Eigenschaften, die keine Basisimplementierung aufweisen.

Warum können wir das nicht tun? Im Fall von Zugriff ist intern das gleiche wie öffentlich, wenn Sie im selben Projekt arbeiten. Dann können wir hier intern nicht verwenden. Es muss einen Grund geben, dass diese öffentlich sein sollten, und ich suche nach diesem Grund.

internal ICommand TestButtonCommand { ...... } 
+3

Da [Sie können nur an öffentliche Eigenschaften, Untereigenschaften und Indexer oder ein beliebiges CLR-Objekt binden] (http://msdn.microsoft.com/en-us/library/ms743643.aspx). Warum hat das WPF-Team eine solche Designentscheidung getroffen? Ich weiß nicht, Sie sollten sie fragen :) –

+0

Sein Microsoft, so können wir nichts tun, –

Antwort

11

Bei internem Zugriff ist das gleiche wie öffentlich, wenn im selben Projekt gearbeitet wird. Dann können wir hier intern nicht verwenden. Es muss einen Grund geben , dass diese öffentlich sein sollten, und ich suche nach diesem Grund.

Sie haben nur in Ihrer Frage zu antworten, da Interna nur innerhalb der gleichen Baugruppe und nicht von außerhalb zugegriffen werden kann. Dies ist der einzige Grund, warum die Bindung an Interna nicht funktioniert, da die Bindung durch das Binden der Engine gelöst wird und nicht durch Ihre Baugruppe und ihre separate Baugruppe, um genau zu sein, wenn Sie danach suchen.

+2

Dann, wie ist es möglich, an Modellklasse zu binden, die selbst intern ist? –

+1

Mann, oh Mann, das hat mich in Winforms verrückt gemacht. Offensichtlich und doch nicht alle gleichzeitig. Vielen Dank. –

7

Binding wird nur für öffentliche Eigenschaften unterstützt. MSDN-Referenz:

http://msdn.microsoft.com/en-us/library/ms743643.aspx

Als

im Referenz zitiert

Die Eigenschaften, die Sie verwenden als Bindungsquelle Eigenschaften für eine Bindung muss öffentlichen Eigenschaften der Klasse sein. Explizit definierte Schnittstelle Eigenschaften können nicht für Bindungszwecke zugegriffen werden, noch kann geschützt werden, private, interne oder virtuelle Eigenschaften, die keine Basis Implementierung haben.

+0

Ich versuche zu finden ist, warum wir nicht intern verwenden können. Es ist dasselbe wie in der Öffentlichkeit, wenn wir im selben Projekt arbeiten. –

0

Erstellt interne Eigenschaft sind gute OO-Design und brechen Einkapselung. Sie können den internen Set-Accessor (und öffentlichen Get Accessor) für Ihren Fall verwenden.

public ICommand SaveCommand 
{ 
    get; 
    internal set; 
} 

Wenn Sie ein Feld in eine Eigenschaft eingekapselt haben, sollten Sie es sich zur Regel machen immer throught eine Eigenschaft, um das Feld zugreifen, auch in Ihrer Klasse. Es ist die beste Vorgehensweise.

1

Die Sichtbarkeit internal ist wirklich nur für den Compiler und den IL-Verifikator von Bedeutung, weil sie den vollständigen Kontext des Memberzugriffs kennen; die WPF-Bindungs-Engine nicht. Es weiß, dass eine Bindung für eine Eigenschaft existiert. Es hat keine Ahnung, wer das Grundstück festgelegt hat. Es könnte in der XAML oder dynamisch zur Laufzeit gesetzt worden sein (technisch, auch wenn Sie es in der XAML setzen, wird es noch dynamisch angewendet).

Da gibt es keine Möglichkeit, die Zugriffsregeln zu erzwingen, so dass die Bindung an internal Eigenschaften wäre gleichbedeutend damit Bindung an private Eigenschaften, nicht public Eigenschaften.

0

Von http://msdn.microsoft.com/en-us/library/ms743643.aspx

Für CLR Eigenschaften, Daten funktioniert, solange die Bindungsmodul Bindungs ​​ ist in der Lage, die Bindung Quelleigenschaft mit Reflexion zuzugreifen. Andernfalls gibt das Bindungsmodul eine Warnung aus, dass die Eigenschaft nicht gefunden werden kann, und verwendet den Fehlerwert oder den Standardwert, wenn verfügbar ist.

2

Offensichtlich hängt es davon ab, was Sie aus dieser Situation zu erreichen versuchen - Sie geben nicht an, was das Gesamtziel ist. Ich bin gerade auf ein ähnliches Problem mit meinem Code gestoßen und habe auch eine Lösung für meinen Fall gefunden. Eine meiner Bibliotheken enthält Hilfsobjekte mit verschiedenen Eigenschaften, aber wenn diese im Anwendungsprojekt verwendet werden, möchte ich nur die Eigenschaften sehen, die für mich nützlich sind - ich wollte zum Beispiel die Eigenschaften des Befehls ausblenden.

Meine Lösung sie von den ‚Nutzer‘ der Bibliothek zu verstecken ist das

<EditorBrowsable(EditorBrowsableState.Never)> 

Attribut jede Eigenschaft hinzuzufügen, die wenig oder gar kein Interesse für mich trägt.

Hoffe, dass jemand hilft!

Verwandte Themen