I’m trying to catalog View-ViewModel Binding Patterns so that I can compare their strengths and weaknesses. So far I can think of 2 basic ones. The names I gave them are made up. What are the others?
Name: View-Instantiation.
Description: The View directly instantiates the ViewModel and assigns it to the data context.
Sample:
<
Window.DataContext
>
<
ViewModels:MyViewModel
/>
</
Window.DataContext
>
Pros: Easy to set up and get going. Easy to add design-time data.
Cons: Requires default constructor on ViewModel. This makes Dependency Injection scenarios difficult.
Name: View Templates
Description: The View is chosen by a data template associated with the ViewModel type.
Pros: ViewModels fit easily into Dependency Injection scenarios.
Cons: Design-time data is more difficult to accommodate. Tooling cannot tell the type of the ViewModel associated to the View during View development.
Yodelay has been updated. I’ve modified the Regular Expression tester so that it supports n-number of test contexts with a single expression. In addition, you can search regexlib.com for a useful expression.
This screen is fully implemented using MVVM. The search window serves as an example of using MVVM with dialogs.
I’ve also pulled in the themes from WpfThemes and integrated the ThemeManager.
Check it out!
The best thing I learned this week was a good way to use MVVM in connection with modal dialogs.I spent a good deal of time scouring the internet for a good answer to this problem. Most of the answers I found involved a lot of code to get up. The issue I have with those kinds of solutions is that if I integrate them into a production project, I’m responsible for supporting them whether I understand all of the code involved or not. I’m sure that over time I’ll acquire the mastery of WPF to be able to create those kinds of solutions, but I don’t have that level of mastery of WPF right now.
The aha moment came with I read this thread: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/0befde65-27e0-43ab-bd9f-6b1df38b7ab3 If you scroll down to the Sergey Pikhulya post (October 8, 2009, 6:42 PM) you’ll find the post I mean. Sergey suggested creating an Interface for IModalViewService, and injecting the an implementation that relies specifically on WPF Windows at run time. In this manner, you can create dummy implementations of IModalViewService for unit-testing your ViewModel.
Honestly, I felt kind of stupid for not thinking of this before. My application already supports injection of configured data services at run time. This is really exactly the same problem with the same solution—just on the presentation/UI layer instead of the data layer.
I thought of a few other solutions to the problem as well.
- Use events. Create events for each time a visual request needs to be made to the user.
- Pros: Easy.
- Cons: you have to create an event for each kind of prompt (message, OK/Cancel, Input).
- Doesn’t easily support specialized data templates for specialized dialogs.
- Leads to an explosion of code as you add new kinds of EventArgs sub-classes.
- You have to write a lot of glue code to make the interaction between MVVM and Xaml happen.
- Create command properties on the ViewModel and assign them in the Xaml.
- Pros: Easy
- You gain good separation because the VM doesn’t need to know how to execute the command, and the use of the dialog is encapsulated in the right layer.
- Cons: You still have a testability problem. If the command logic is complex, you are putting a lot of untestable code in the UI layer.
- Pros: Easy