2011-09-09 5 views
1

両方のICommandオブジェクトがViewModelにバインドされています。ViewModelで新しいICommandオブジェクトを作成する

最初のアプローチは頻繁に使用されるようです。

しかし、2行目はいくつかのコード行を保存しますが、Bindingがリフレッシュされるたびに新しいICommandオブジェクトを作成することはありません。

private LightCommand _deleteDocumentCommand; 
     public LightCommand DeleteDocumentCommand 
     { 
      get { return _deleteDocumentCommand ?? (_deleteDocumentCommand = new LightCommand(() => DeleteDocument(),() => CanDeleteDocument)); } 
     } 

     public LightCommand DeleteDocumentCommand 
     { 
      get { return new LightCommand(() => DeleteDocument(),() => CanDeleteDocument); } 
     } 

答えて

0

はいそうです。これを一度インスタンス化するほうがよいので、次のようなことがあります。

LightCommand DeleteCommand { get; set;} 

次に、VMインスタンス化では、そのインスタンスを割り当てます。または、最初の例を使用することもできます。

+0

あなたが示唆したように私はそのアプローチが好きです - なぜ? – msfanboy

0

私はあなたが検証を探していると仮定し、それは正しいです:

毎回バインディングは、リフレッシュされる(またはコマンドが呼び出される)、新しいオブジェクトをインスタンス化されます。それは明らかに資源の浪費のようです。

1

はい2番目の方法では、コマンドが参照されるたびに新しいコマンドが作成されますが、第1の方法は読みにくくなります。 ViewModelににコマンドを作るために

私の好ましい方法は、それはより多くのコード行であるかもしれないが、読んで理解しやすいです

private LightCommand _deleteDocumentCommand; 
public LightCommand DeleteDocumentCommand 
{ 
    get 
    { 
     if (_deleteDocumentCommand == null) 
     { 
      _deleteDocumentCommand = new LightCommand(
       () => DeleteDocument(),() => CanDeleteDocument); 
     } 

     return _deleteDocumentCommand; 
    } 
} 

です。また、通常は私の公開プロパティ/コマンドはすべてマクロによって生成され、ViewModelで作業するたびに縮まった#region Properties領域にダンプされるので、get/setメソッドのページをスクロールする必要はありません。

+0

"最初のメソッドは、オブジェクトが最初に「正しくない」コマンドを取得したときにnullを返します。ヌル合体演算子 "??" nullが??の後の値を返す場合したがってnullを返すことはできません。 – msfanboy

+0

@msfanboyそうです、答えを更新します。私は何かを考えていた – Rachel

関連する問題