8

一般的に、私はWindow以前にそれ自体のプロパティを初期化し、InitializeComponent()その後に含まれるコントロールを設定してきました。しかし、私はそれほど一貫性がなく、注文の問題にも気づいていません。それで：

  • 私は（潜在的に）何か恐ろしいことをしていますか？特に、以前に子コントロールのプロパティを設定することに問題はありますInitializeComponent()か？
  • この点で良いスタイルは何ですか？

編集：私が得た最初の2つの答えは少し矛盾していたので、より具体的にしましょう：

public Foo Foo {get; protected set}
public FooWindow (Foo foo)
{
    Foo = foo;
    this.Closing += FooWindow_Closing;
    Foo.Frobbed += Foo_Frobbed;

    InitializeComponent();

    this.DataContext = this;
    this.Title = Foo.Name() + " Window";

    FooListView.ItemSource = Foo.CalculateList();

    FocusManager.SetFocusedElement(this, FooListView);
}

これは正しいですか？MVVMを実行しているだけで、Windowコンストラクターに何も含まれていない必要がありますか？

4

3 に答える 3

6

他のコードの後に​​InitializeComponentsを呼び出すと、XAMLで設定されたものでプロパティを誤って上書きしたり、初期化されていないオブジェクトを使用したりするリスクがあります。通常、コードビハインドはXAMLよりも優先度が高いため、InitializeComponents（つまり、XAMLの解析と読み込み）を最上位のままにします。

于 2012-07-13T23:12:35.077 に答える
4

あなたの特定の質問に答えて：

私は（潜在的に）何か恐ろしいことをしていますか？特に、InitializeComponent（）の前に子コントロールのプロパティを設定することに問題はありますか？

InitializeComponentsを呼び出すまで、子コントロールをコードで使用できない可能性があります。これを行うのは一般的に悪い形です。

この点で良いスタイルは何ですか？

これは好みの問題になりますが、一般的に、XAMLが提供する分離を利用する場合は、可能な限りそれを利用することをお勧めします。UIについて論理的に行うことを行う場合は、XAMLでそれを実行してみてください。これは、プレゼンテーションとロジックの分離であるため、MVVMの問題ではありません。サンプルコードにあるもののほとんどは、ValueConvertersを使用した場合でも、宣言的に実行できます。

たとえば、FooがDependencyPropertyの場合、XAMLにアタッチして、ValueChangedコールバックの一部としてコールバックを追加することもできます。繰り返しますが、これはMVVMではありませんが、WPFの基本です。

他のほとんどの場合、コンストラクターで作業を行うのではなく、実際にはOnLoadedが呼び出されるまで待ちたいと思うでしょう。

お役に立てば幸いです。

于 2012-07-17T22:55:35.657 に答える
2

私は通常、 InitializeComponent（）を呼び出す前に、ビジュアルツリーを必要としないものをすべて呼び出します。

私の実装はすべてMVVMパターンを使用しているため、UIがクライアントに読み込まれる前に、ViewModelをインスタンス化してデータを設定することを好みます。

常にInitializeComponent（）を最初にロードすると、突然更新される未入力のビューと、表示されたときに入力されたビューを表示することで、ユーザーエクスペリエンスが低下するリスクがあります。

于 2012-07-14T15:12:17.230 に答える