0

ここの賢い人が、UI アイテムを操作するときにバインドを使用する必要があることを教えてくれました。さて、私は束縛の話題に少し慣れましたが、私の心を強姦し続ける奇妙なことが1つあります. 私の問題をよりよく説明できるように、例を作りましょう。

xaml コード:

<TextBox x:Name="MyTextBox" 
                 Text="Text" 
                 Foreground="{Binding Brush1, Mode=OneWay}"/>

c# コード:

public class MyColors : INotifyPropertyChanged
{
    private SolidColorBrush _Brush1;

    // Declare the PropertyChanged event.
    public event PropertyChangedEventHandler PropertyChanged;

    // Create the property that will be the source of the binding.
    public SolidColorBrush Brush1
    {
        get { return _Brush1; }
        set
        {
            _Brush1 = value;
            // Call NotifyPropertyChanged when the source property 
            // is updated.
            NotifyPropertyChanged("Brush1");
        }
    }


    // NotifyPropertyChanged will raise the PropertyChanged event, 
    // passing the source property that is being updated.
    public void NotifyPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this,
                new PropertyChangedEventArgs(propertyName));
        }
    }

前景の色を変更するには、コードでこれを簡単に記述できます。

MyColors textcolor = new MyColors();

        // Brush1 is set to be a SolidColorBrush with the value Red.
        textcolor.Brush1 = new SolidColorBrush(Colors.Red);

        // Set the DataContext of the TextBox MyTextBox.
       // MyTextBox.DataContext = textcolor;
        MyTextBox.Foreground = new SolidColorBrush(Colors.Blue);

ふう、ついに手に入れました。次に、私が使用した 2 番目のソリューションに進みましょう。

xaml:

<TextBox x:Name="MyTextBox"/>

c#: MyTextBox.Foreground = new SolidColorBrush(Colors.Red);

なんと、同じ効果 :o では、私の質問は次のとおりです。

このことを超えて、どんな入札が私に与えますか? この時点では、結果に大きな違いは見られません。最初の例ではさらに多くのスペースが必要で、偶数が実装されていて、2 番目の例では 2 行かかることを期待してください。msdnの例では明確な答えが得られないため、誰でも便利な良い例を教えてもらえますか。

4

2 に答える 2

2

最初の方法 (MVVM デザイン パターンを使用) はビューモデルをビューから分離するため、テストが容易になり、短時間で他のプラットフォームに移行できるようになります。

2 番目の方法は簡単ですが、密結合です。MVVM 設計パターンを読んで、その利点の全体像を把握してください。

于 2013-03-24T07:54:45.937 に答える
0

まず最初に...あなたの質問では、 MyTextBox.DataContext を設定する行をコメントアウトしたので、その時点でバインディングを使用していません。次に、次の行で、値を直接 Blue に設定します。これは、入力した他のすべての値が使用されていないことを意味します。なぜそんなことをしたのかわかりませんが、それは少し的外れです。単なるタイプミスかもしれませんが、あなたの意図がわからないので編集しません。

質問の「要点」にたどり着くと、前述のように、最初に行った方法は、MVVM または Model-View-ViewModel パターンに従います。モデルはデータ、またはこの場合はブラシです。View は TextBox で、ViewModel は MyColors と呼ばれるものです。ViewModel は IPropertyChanged を実装しているため、リスナー (バインディングなど) がリッスンする変更通知を発生させることができます。

2 番目のケース (コード ビハインドで値を直接設定するだけ) で行った方法の代わりに MVVM を使用して設計する理由は、コードの関心の分離に関係しています。具体的には、アプリケーションのロジックとそのビジネス ルールが UI のロジックから分離されています。

たとえば、ビジネス ロジックで「エラー テキストは赤にする必要がある」と言う場合があるため、ViewModel で ErrorTextBrush というプロパティを公開できます。TextBox の名前が何であるか、または画面に表示されるかどうかについて考える必要はありません。ビジネス上の懸念を UI の懸念から分離しました。

同様に、UI の開発者は、ビジネス ロジックに関連することを考える必要はありません。知っておく必要があるのは、画面上の TextBox をエラー テキストのプレースホルダーとして定義していることだけです。そのため、ErrorTextBox.Foreground を ErrorTextBrush にバインドするだけで、UI はビジネス ロジックの指示に従います。

実際には、ビジネス ロジックではなくビューに関連しているため、XAML で ErrorTextBrush を定義することもできます (実際にはそうするべきです)。次に、ViewModel に HasError のようなプロパティを設定し、XAML でトリガーまたはバインディングを設定します。エラーが発生した場合はそのエラー ブラシを使用し、それ以外の場合は標準ブラシを使用します。

この場合、ビジネス ロジックは、テキストが赤であることを認識する必要さえありません。それはUIによって完全に決定されます。逆に言えば、UI はエラーの原因を知る必要はまったくありません。エラーがあったことを知る必要があるだけなので、それを反映したビジュアルをユーザーに表示する必要があります。

また、前述のように、ViewModel は単なる通常のクラスであり、単体テストを実行しやすくする UI ではありません。たとえば、上記の例を使用してテストするには、ViewModel をインスタンス化し、エラーをトリガーする条件を設定してから、HasError プロパティがトリップするかどうかをテストするだけです。UI がまったくなくても、これらすべてを実行できます。

これにより、開発者はアプリケーションのロジックに取り組むことができ、デザイナーはほとんど対話することなく UI に取り組むことができます。ほとんどの場合、UI が知る必要があることだけを交換する必要があり、それ以外のことはほとんど必要ありません。

于 2013-03-24T08:22:48.637 に答える