あなたの理解を明確にさせてください:
はい、コード ビハインドのコードは一般的に回避されますが、これは、MVVM を使用すると、視覚要素を舞台裏の機能と結び付けるためにビューモデルのプロパティとコマンドにバインドすることが非常に簡単になるためです。
ビューのコード ビハインドでビュー固有のコードは、問題の境界を越えないと仮定して、完全に許容されます。たとえば、アプリケーションにページの視覚処理を行うビューがあり、そのためにはビューにコードが必要です。このコードはビューモデル レイヤーともやり取りする可能性がありますが、ビューモデルを直接参照しないため、コンポーネントが疎結合されたままになります
特定のメソッド呼び出しが必要なコントロールがある場合、イベント アグリゲーター メッセージを作成して通知をビューに伝達することは問題ありません。これは、ビューモデルとビューの間で関心の分離を維持しているためです (アプリケーション コンポーネントはカプセル化され、テスト可能のままです)。
例のビュー (わかりやすくするために、すべてのイベント アグリゲーター ワイヤアップ コードと潜在的な依存性注入のものを残しました):
public class MyView : IHandle<SomeNotificationMessageType>
{
// Handler for event aggregator messages of type SomeNotificationMessageType
public void Handle(SomeNotificationMessageType message)
{
// Call a method on one of the page controls
SomePageControl.SomeMethod();
}
}
明らかに、ViewModel で次のようなことを行う必要はありません。
public class MyViewModel : IViewAware
{
public void DoSomethingThatAffectsView()
{
var view = this.GetView() as MyView;
view.SomePageControl.SomeMethod();
}
}
MyViewModel と MyView を緊密に結合しているため、これは MVVM の原則に違反しています。
Context
同じビューモデルで複数のビューを許可する caliburn microのプロパティを使用したい場合はどうすればよいでしょうか? 上記のコードは壊れます - ビュー タイプをチェックしたとしても、スパゲッティ コードで終わるでしょう。
public class MyViewModel : IViewAware
{
public void DoSomethingThatAffectsView()
{
var myview = this.GetView() as MyView;
if(myview != null)
myview.SomePageControl.SomeMethod();
var myotherview = this.GetView() as MyOtherView;
if(myotherview != null)
myotherview.SomePageControl.SomeMethod();
// ad infinitum...
}
}
もちろん、これは主観的なものです。ユーザーコントロールがビューモデルとビューに複雑な方法で影響を与える可能性があります。その場合、アーキテクチャを調べて、ユーザーコントロールがどのように適合するかを検討することをお勧めします
UC とは何か、UC のメソッドが何をするのかについての背景はありますか?