I have some xaml like:
<ContentControl x:Name="MyContent" />
and then on my ViewModel there is, of course, a MyContent property which references a ViewModel. Then Caliburn does its compositional magic.
This is great, but in design time I can't see the composition. I see 'most' people raving about the view model first approach, but I'm a little baffled as to whether there's a way to leverage the designer when doing this that I haven't yet realized or do all the vm first people just live with the fact that they have to run the application to see what it's going to look like?
Speaking about WPF Binding compared to Qt, did anybody tried to achieve the functionality that in WPF achived by the following:
<ComboBox ItemsSource="{Binding Items}" SelectedValue="{Binding SelectedItem}" />
Here are:
Items collection (member of the Model) bound as a source of combo drop down.
Then combo selection bound to SelectedItem (member of the Model).
In Qt:
Could relatively easy achieved by QComboBox.setModel().
Is a bit harder because it's two-way binding. View-to-model changes could be done with signals (QComboBox.activatedIndexChanged). Model-to-view changes could be also done through signals (to follow Model-View separation you'll need to add signal to your model, emit it whenever SelectedItemIndex is changed on the model, and on Widget side connect to that signal for calling QComboBox.setCurrentIndex()).
All these seemed to be very general things and could be done in separate library of binding helpers. For example, I have right now in my QtJambi code something like this:
ComboBoxBind bind = new ComboBoxBind(comboBox);
bind.selectedIndex(model, "SelectedItemIndex").items(model.getItems());
The currentIndex of QComboBox here is bound to SelectedItemIndex member of the model (with corresponding get/set methods). So I can call setSelectedItemIndex on model or change selection in UI - model will be insync with view.
The question is: Does anybody know if the Binding library already exists? Has anybody tried to create something similar?
Sorry, it could be that I'm missing something. I'm pretty experienced in WPF but just started with Qt and developing UI with QtJambi right now. Any comments/ideas are welcome!
This question is related to this one: Qt equivalent of .NET data binding?, but I think question there wasn't answered at all. At least it doesn't provide any sample of WPF-similiar Binding in Qt.
I want to know why we should use MVVM to implement Silverlight app. What're it's advantages?
We don't do Unit Test for ViewModel, so I want other reasons.
Below are my questions about some advantages people usually say:
1.Loosely Coupled : When we use MVVM , a view rely on ViewModel but not a view, why it's loosely coupled?
2.If I provide public methods in a code-behind, they can also provide reusability.
Well, the unit-testability of the view-model is a significant advantage, so you'll miss out on that benefit. Regarding the other two:
Loosely coupled
Yes, the view does rely on the view-model. They have to be connected in some way to accomplish the function of the application. As a result, they cannot be uncoupled. The only choices are tightly-coupled or loosely-coupled or somewhere in between. With MVVM your view-model interacts with your view in a very limited way: basically just objects, properties and commands. Compare this to doing everything in the code-behind where the view and its control are essentially inseparable.
Re-use
If any code in your code-behind is re-usable enough to merit being public, it can be taken out of the code-behind and put into a general-purpose class. The problem is that what's left after that is not reusable.
If you don't want to go into the MVVM deep dive, then you can get some of the benefits of MVVM by focusing on databinding. After you learn the benefits of databinding, you can reconsider the other benefits of MVVM.
We don't do Unit Test for ViewModel,
With MVVM, it isn't just about unit testing ViewModel. Ideally, your VM should be very thin and only have properties needed by view. So, it isn't really necessary to test the VM.
But, without a VM, how do you do your your feature/functional testing across layers? In Silverlight, to facilitate testing you should use commands, instead of writing code in code-behind files. This allows you to simulate button click and other GUI events while unit testing. Using MVVM pattern along with commands, you can test all of C# code (not xaml), right up to UI (Converter, VMs, etc).
If I provide public methods in a
code-behind, they can also provide
reusability.
Not going into details of how that is a bad design, I want to ask you, How does that provide reusablity? If you create a user control, then the code-behind class is a control? You want to create instances of your control and use them? This is like saying that why do we need member methods, we can just create public static methods and access them. I have a strong opinion that if we don't want to use the automatic binding provided by WPF/Silverlight, then it is better NOT to use these technologies. And to exploit the full capabilities of binding, MVVM is essential.
why it's loosely coupled?
VM is very much part of your view. It is not decoupled from the view. As I have said, your VM should be as thin as possible with only public properties needed by your view. Your business logic will be decoupled from your view (and VM).
I think this is one of the best resources available, in case you want to use and contrast the usage of MVVM vs. ANY other pattern or no pattern.
http://karlshifflett.wordpress.com/2010/11/07/in-the-box-ndash-mvvm-training/
I can answer how I use MVVM pattern.
MVVM is better in the following scenarios:
1 If several controls are bound with a single property.
MVVM:
<TextBlock x:Name="text1" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>
<TextBlock x:Name="text2" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>
I can quickly add a similar control or remove an existing control.
Compare with code-behind:
public string IsSomePropertyTrue
{
set
{
//...
text1.Visibility = value;
text2.Visibility = value;
}
}
2 Instead of a multi-converter
public Brush StateColor
{
get
{
if (this.State == State.Edited && this.IsPriority)
return new SolidColorBrush(Color.FromArgb(255, 0, 255, 0));
//...
}
}
<sdk:DataGridTemplateColumn.CellTemplate>
<DataTemplate>
<TextBlock Background="{Binding StateColor}" Text="{Binding State}"/>
</DataTemplate>
</sdk:DataGridTemplateColumn.CellTemplate>
3 As an item model in controls like ListBox or DataGrid. For example, if I want to create a list of items with a remove button near each item, I will create a ItemView control and a ItemViewModel class.
<ItemsControl ItemsSource="{Binding SomeItems}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<view:ItemView DataContext="{Binding}"/>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
4 Copying a data from one view to another:
public JournalEntryViewModel(SalesOrderViewModel vm) {}
5 ViewModel can inherit CLR-classes and implement interfaces (INotifyPropertyChanged or INotifyDataErrorInfo).
Also I use MVVM for replacing events with commands or properties. And use of ViewModels forces to call properties by intelligible names.
I was an early adopter for WPF and I can tell you what made me choose MVVM (and this more or less applies to Silverlight as well). For the project I was working on, I had to create a screen that allowed users to subscribe to notifications within the system. This was a 3 step process:
The user had to search for the item they wanted to be notified about
They had to select the item and fill out additional options regarding the subscription
The system had to provide a summary and allow the user to confirm or edit the subscription.
After implementing the functionality the first time (without MVVM), I was told that we need to exclude from the search items that were already subscribed to by the user.
After making that fix, I was informed that we needed to give the user a live preview of the subscription based on options.
By then I started noticing that some of these changes could be extracted and made easier if I didn't have to deal with manipulating the UI as I changed the logic. I had never intentionally followed MVVM but I realized that the abstraction that I made closely matched the MVVM pattern.
So this is why I recommend the pattern. It simplifies the task of changing the logic that drives the UI by separating it from the UI itself. I also would recommend that you hold off implementing it until you need it. There is a cost to using MVVM but it is amortized over the cost of changing the UI logic.
Without MVVM, your Silverlight app code very soon will turn into unmanageable mess
What is also interesting in MVVM is dynamic automatic binding.
Imagine, that your view model has properties like this: bool IsFirstNameVisible, bool IsFirstNameEnabled, string FirstName, double FirstNameWidth etc.
In your XAML file, you define TextBox with x:Name = "FirstName" and call your dynamic MVVM-binder. It inspects your view model class via reflection, looks what properties you have defined and binds them dynamically to similar properties of control with the same name, applying value converters if needed.
In this case, your get very clean XAML, without kilometer-long data-binding expressions and converters.
That is what my MVVM library does.
Separation of Conerns people. Separation of Concerns.
Forget unit testing (I love it; but that's not the thing here). Forget reusability (do you really re-use view models? No, let's be real here).
It's about Separation of Concerns and putting code and logic where it belongs. The whole idea is maintainability; being able to make changes to the code as it evolves over time without breaking other stuff and without turning the whole thing into a big pile of spaghetti.
MVVM, done properly, allows your code to be separated into logical portions that make sense and allow for reasy refactoring and change as the app's requirements change. It's easier to find where something is when you need to make a change. Trying writing any halfway complex application and then leaving it alone for a month, then coming back to it and trying to make significant changes. A properly structured application with judicious use of MVVM is way easier to grok after a layoff, and it's way easier to make changes.
Does anybody have an idea how to change screens (views) in a MVVM View-First-Approach (The view instantiates the ViewModel:
DataContext="{Binding Source={StaticResource VMLocator},
Path=Find[EntranceViewModel]}"
)
For example:
In my MainWindow (Shell) I show a entrance view with a Button "GoToBeach".
<Window>
<DockPanel>
<TextBox DockPanel.Dock="Top" Text="{Binding Title}" />
<view.EntranceView DockPanel.Dock="Top" />
</DockPanel>
</Window>
When the button is clicked I want to get rid of the "EntranceView" and show the "BeachView".
I am really curious if somebody knows a way to keep the View-First Approach and change the screen (view) to the "BeachView".
I know there are several ways to implement it in a ViewModel-First Approach, but that is not the question.
Perhabs I missed something in my mvvm investigation and can't see the wood for the trees... otherwise i am
hoping for a inspiring discussion.
One possibility would be to have all views in the (MainWindow(Shell) and using Triggers for their visibility. But having a lot of different screens (views) all declared in the MainWindow doesnt feel right for me...
This question came up while reading this nice way of using MEF with MVVM I found on John Papas Blog: Simple ViewModel Locator for MVVM: The Patients Have Left the Asylum . But as nice as this marriage of view and viewmodel is, it seems like there is no way to change screens that satisfies me. :)
So in my opinion if you have a lot of screens(views) you better use a ViewModel-First-Approach...
This looks like it might help:
Creating a ViewModel : do it before or after model data is available?
Failing that, how about creating the ViewModel once only at startup, and assigning it to each View window as it's created (rather than creating a new ViewModel each time). Then just close the first View and open up a new View as required, reassigning the single ViewModel instance.
You may want to look at Prism (i.e. the composite application library). Prism facilitates navigation between views via the region manager. This might be overkill for your application and can take a while to get your head around. Prism also allows you to develop using the MVVM pattern as well.
You can find more information about prism and prism navigation in the Prism documentation.
I'm starting to use Binding in my WPF project and I'm actually confused about few things on the presentation side (XAML).
So I want to populate a TreeView with a List of Categories. I know how to write the right HierarchicalDataTemplate for my List of Category instances.
<HierarchicalDataTemplate ItemsSource="{Binding Path=ChildrenCategories}" DataType="{x:Type src:Category}">
<TextBlock Text="{Binding Path=Name}"></TextBlock>
</HierarchicalDataTemplate>
But what now I don't know is from where to get the list. I have here 2 solutions :
I got a Library Singleton class
which return me the right
arborescence, then I need to use an
ObjectDataProvider in my xaml which
would call the
Library.Instance.Categories method. (Which means that the controller has to be completely separated from the UI).
I got a Property ListCategories
in my page interactionLogic
(OpenUnit.xaml.cs), and bind the
tree with it.
I'm not sure about the purpose of the xaml.cs files, what are they made for? Is it normally used to store the properties (and act as a controller) or simply to have a back-end for the UI (for example get values from the UI?)?
In case the xaml.cs file is used as a controller, how do I bind my data to it, I've tried many solutions without success,my only success was with the use of static binding.
I would appreciate any comment or recommandation about UI and Logic Binding in WPF, hopefully I will get less confused.
Thanks in advance,
Boris
After reading this great article, I got a little bit less confused :
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
The article is about the Model View ViewController pattern, and how WPF integrates it. So it seems that xaml.cs files should be used as the ViewController here, and should hold the properties.
It actually make sense since it's not a good practice to mix the View and the Data, we want the designers should have a completely independant work to do.
Also for the solution 2) it is possible if you set the data context to the current file.