2012-04-27 32 views
0

私はCaliburn.Microを使い始めました。すべての例ですべてが公開されています。私はこの方法を追加私のVMでCaliburn.Microがすべてのメソッドを公開する必要がありますか

x:Name="CloseMainWindow" 

::私は、ボタンを追加することでこれをテストすることを決めた私はボタンをクリックすると

private void CloseMainWindow() 
{ 
    TryClose(); 
} 

を、何も起こりませんし、私はブレークポイントにヒットしていません、メソッドをpublicに変更しても機能します。 これを行うための最良の方法はわかりません。

すべてのメソッドのICommandプロパティを作成できますか?

編集:私はちょうど上記の質問への答えを読んで、Caliburn.MicroにはICommandsがありません。だから私の元々の質問にはまだ答えが必要ですが、なぜすべてがVMに公開されなければならないのですが、これは安全ですか?

答えて

0

「これは安全ですか?」という意味は分かりません。何よりも安全ですか?

とにかく、Caliburn.Micro は、その規約がプライベートメソッドにバインドできるように設計されていますが、それにはいくつかの欠点があります。まず、SilverlightやXBAPやサンドボックスプラグインなどの部分信頼環境では動作しません。 Reflectionを使用してプライベートメンバーにアクセスするには完全な信頼が必要であり、Caliburn.Microは部分信頼で実行できるように設計されています(Silverlightをサポートしています)。

しかし、大きな理由はカプセル化に違反するということです。これらは、がクラス外から呼び出されることを意図したメソッドです。 (ビューは独立したクラスなので、コードビハインドで自分自身を配線する場合は、viewmodelメソッドをpublicにする必要があります)。 "私は自分のクラスの外から呼び出すつもりです"と言います。それはpublicです。クラス外からプライベートメソッドを呼び出すいくつかの魔法を設定した場合、カプセル化とLeast Astonishmentの原理に違反しています。なぜならそれはprivateの意味ではないからです。

プライベートメソッドに本当にバインドできるようにしたい場合は、規約をカスタマイズできます。しかし、それはあなたのコードを理解するのがずっと難しくなるので、あなたが本当に良い正当化を思い付かない限り、私はそれをお勧めしません。

+0

ごめんなさい。私はできるだけプライベートを使うように教えられていました。私は誰かがあなたのメソッドにアクセスし、それを公開した場合は意図していないときにそれを実行できると言われました。変数の代わりにプロパティを使用する理由は同じです。私が教えたことはあまりにも厳しいですか?私はまだ学んでいます、私たちは皆ですか? –

+0

APIを書いているなら、publicメソッドはprivateよりも慎重に書かなければなりません。 (EXEを書いているのであれば気にする必要はありませんが、他のユーザーが使用する予定のDLLについては重要です)。APIで実装の詳細や依存関係を公開する必要はありません。たとえば、他の "init"メソッドを最初に呼び出さなかった場合は爆発します。あなたはそれを秘密にして逃げることができます。しかし、ボタンのクリックはパブリックメソッドと同じように(それ以上ではない場合)、実装の詳細を隠している方が良いでしょう。 –

関連する問題