We are wiring up our views and view models "externally" meaning we have the following type of code somewhere:
var viewModel = new MyViewModel();
var view = Application.Current.FindResource("MyView") as UserControl;
view.DataContext = viewModel;
That is a paraphrase of sorts. We do this so that the dll containing all of the views can be switched out at run-time. So long as the dll defines a resource named "MyView" that points to the usercontrol MyView all is good.
My concern is just to make sure that FindResource does not suffer or is inferior in a meaningful way to just doing the following:
var view = new MyView();
This could be replaced with IoC. (We don't allow the user to switch which view DLL is used. It开发者_JAVA技巧 is determined when the app starts.)
One thing with FindResource I have found is that you may have to use x:Shared="False"
or else WPF will hand you back an existing instance and you must make sure it is "initalized" back to its original state.
Any thoughts?
Declaring UIElement instances as Resources is almost always a bad idea. You've already seen one of the major issues with doing it (and workaround). It's also very easy to cause memory leaks because items in the App level Resources are instantiated at startup and stay there until the app is closed (unless you do more manual work to force them to clean up).
Using templates is a much better solution and it should be very easy to convert from what you're already doing. The template will instantiate new instances of its child elements as needed and inject them locally as if they were declared inline. Just wrap your existing UserControl declarations in DataTemplate elements and move the x:Key declarations. Then when you get to the code above (could also be done in XAML or possibly implicitly with DataType templates) do:
var viewModel = new MyViewModel();
var view = Application.Current.FindResource("MyView") as DataTemplate;
var control = new ContentControl { Content = viewModel, ContentTemplate = view };
精彩评论